select: provide a way for authors to define the string value of rich options

Introducing the ability to render structured rich content within options also introduces the need for authors to be able to separately define the rendered DOM in the option vs. the string-typed text used for features like typeahead / type-to-navigate.

I ran into this exact issue while creating the Dropdown & Combobox controls in the library I work on. A concrete example can be found in UI like this:

When displaying the selected value in the trigger button we only want to display the text of the person's name. This is currently possible using <selectedoption> + custom CSS display: none styles. What isn't currently possible is enabling users to type e.g "Elv" to jump to "Elvia Atkins", Or repeatedly typing the same letter to cycle through multiple people whose names all start with that letter.

The best we can do as a browser fallback is to use the text content of the entire option, which is not always conceptually the text that a user would try to type. That still seems fine to me as a default, but authors who want to do the right thing currently have no ability to customize this.

The other potential reason for needing this is if we keep the same <option> model & attributes in a future editable select, there will need to be a way to define what string-only value gets inserted into the <input> when an option is selected.

Solutions

There are a couple current HTML attributes on the option element that are at least conceptually similar to this idea:

• label: right now this overrides the displayed text of the <option> if defined. Repurposing this to no longer override the text could be considered breaking (maybe?), although otherwise this feels like a good fit.
• value: even though the word "value" captures the idea of this feature, repurposing current behavior of value -- which is the form-submitted non-human-readable value -- would be a bigger and more breaking change.

The other option (heh) is to create a new HTML attribute specifically for the string version of option's primary text. This is what we do in my library, using text. For example, the options in the above screenshot have roughly this code:

<Option text="Elvia Atkins" value="eatkins">
  <Avatar />
  Elvia Atkins
  <span class="status">Busy</span>
</Option>

Open questions:

• Assuming we add or repurpose an attribute for this, should that attribute ever be used as the displayed text in the select trigger?
• Should it ever be used in the calculation of the accessible value string? (which should probably match the displayed text most of the time)

Related: #1117

Start by reading the existing option/select model and related issue #1117, then compare the proposed uses of label, value, and a new text attribute. Review the open questions about trigger display and accessible value strings; done means the attribute and its behavior for typeahead, type-to-navigate, and future editable selects are specified.