feat: combobox custom options issue#3201

[Steven7926]

Summary

Related Issues or PRs

Closes #3201

How To Test

1. Use the ComboBox and in the options passed to it, include a render function that returns the JSX to use for the option.

const options = Object.entries(fruits).map(([key, value]) => ({
  value: key,
  label: value,
  render: () => {
    return (
      <div className="padding-2 border border-base-lighter radius-md bg-white">
        <div className="font-sans-md text-bold">
          {value}
        </div>
        <div className="font-sans-sm text-base">
          Category: Fruit
        </div>
      </div>
    )
  }
}))

2. Pass the options as the options prop to the ComboBox
3. Click on the ComboBox and notice the options are rendered using the custom JSX you passed.

[brandonlenz]

When a maintainer has time to review and consider these changes, some things to evaluate:

1. At some point <option> tags could only contain strings. Looks like that's no longer the case, but only for modern browsers
2. The USWDS implementation only uses strings, so this is a case of balancing flexibility with potential footguns for consumers
3. Consider the impacts on filtering. One of the core features of the combobox is to filter options by label against default or custom regex. It will be important for consumers to follow the USWDS guidance, if they're now able to render options that don't match their labels:

   Use option strings familiar to users. The combo box filters by matching strings. Include option text that includes familiar strings or spellings (for example, if using the combobox with a state list, include the postal abbreviation in the option text: District of Columbia (DC)).

I bet we'll want to document somewhere the details about filtering so that consumers don't get confused if their custom rendered content doesn't filter neatly if not tied closely to the label prop that they pass in