Improvement: Determine how we'll handle the desire for different option data shapes

[jackkoppa]

@EvanSanderson & @jackkoppa have recently discussed the way we'd like to handle different data shapes for passed in options going forward. We'd like to:

1. Maintain extremely usable & accessible components
2. Get the benefits of useful & consistent TypeScript information wherever possible in those components
3. Allow for any users of those components to meet their usage needs

We think we need to balance 1+2 vs. 3 in this case, to make sure that whatever flexibility we add to the components does not make them too unwieldy, in terms of general maintenance or TypeScript in particular.

The type of flexibility we're talking about:

// currently, only accept options that look like this:
[{
  label: 'Some string label',
  value: 'some string value'
}]

// but what if a consuming app has options shaped like this
[{
  displayLabel: 'Some string label',
  value: { maybe: 'an object'},
  uniqueId: '12345'
}]

// or we could take it even further from the current options, & consider
['option 1', 'option two']

^ which of the above do we want to try to accommodate? Or others? And if more than one, how to accommodate those

Some example PRs to consider:
#51 - we're pretty sure we'll revert this. We've decided against adding new value types one-by-one & attempting to generate their unique ids here. We need a somewhat broader approach
#53 - an excellent contribution from Felixclement, this would get us close to maximum flexibility, and is worth considering

Noting also that, perhaps before we make any final decision & PR on this question, we'll also want to add some initial specs so that any new use cases (new data shapes) can be appropriately tested.

cc @RED143, @ee923925github

[jackkoppa]

Note - w/ @EvanSanderson, @RED143, @ee923925github, and others, we've discussed the goals for this ticket. And we're agreed that we should expand our flexibility, for the sake of our own internal cases, as well as future external cases. The approach in #53 is very close to the route that I think we'll end up going.

I want to make a few adjustments there - valueField should be something more like uniqueIdField, even if we keep the default as value for now.

And, importantly, now that we can, we'll want to add some basic specs to go along with that.

Anyone can make these changes to that PR (maybe as a separate branch that we can later merge in), but I had volunteered to do so & am still happy to do them. It will just need to wait for after my PTO, if that's the case, so the week following Christmas. Will check back in then!

[jackkoppa]

Addressed in #75!
And specs added in #77

Huge shoutout to @Felixclement!

Will close this issue when above 2 PRs are merged