Enterprise: Dropdown/Multiselect: Refactor to use a datasource object as opposed to a Select element

NOTE: This issue potentially addresses some performance problems identified in #843 (and others).

Is your feature request related to a problem? Please describe.
The current Dropdown/Multiselect we ship with IDS was created as an interaction layer over top of the standard HTML <select> element, handling the selection of its options in both single/multiple settings.

The use cases for this component have increased over time to include filtering of the available options, which has led to teams using the Dropdown/Multiselect for extremely large datasets (topping over 2000 items at a time, in some cases). While our team retains that we don't recommend using this component for datasets this large, we continue to get issues requesting that we address performance at these levels. Some previous issues we've fixed include:

• https://jira.infor.com/browse/SOHO-5693
• https://jira.infor.com/browse/SOHO-5192
• https://jira.infor.com/browse/SOHO-7816
• #843 being the latest

Many of those issues leave the caveat of "this is still not great but it's better". The reason for this is because the design of the Dropdown/Multiselect at its core doesn't lend itself well to datasets this large. If we want to fix performance problems, we need to address the fundamentals of its design.

Describe the solution you'd like
A possible solution path for fixing performance of Dropdown/Multiselect:

• [ ] A hard requirement of using <select> as the primary datasource. Some recent improvements from #267 began to map out how an AJAX call might generate a data object for Dropdown that we can store on the client. I think that we should move toward using an object with some simple states (disabled/selected/etc) as the primary driver of the component's behavior, instead of grabbing this information from a DOM element. The rendering of the <select> tag and its <option>s will still be necessary for things like form submission, but we should define the data object as the "source of truth", and draw the select tag based on the object (not vice-versa).
• [ ] Also explore simply not rendering/having a dependence on a <select> tag in any sense. It may be a reasonable use case for a developer utilizing the Dropdown/Multiselect with this many items to simply intercept a request for form submission, and send the state of the datasource object instead of relying on the normal form submission process. Currently, this type of use isn't possible.
• [ ] Once we no longer rely on the DOM element, we can begin to explore only displaying a subset of list items in the DOM at any given time. Since the state is retained by the datasource object, the DOM doesn't necessarily matter, and it should be much more trivial to load/unload small amounts of list items as a user scrolls through a list (would allow us to explore #460 on Dropdown).
• [ ] Create better recommendations for server-side handling of large datasets. Even retaining state in a client-side object with that many records can eventually get very slow. We might want to have a recommendation and/or some demos of how we might want implementations of IDS to handle Dropdown/Multiselect records on the server.

Describe alternatives you've considered
Some other ideas that we've floated in the past:

• A simpler component that overlays <select> tags and styles them, instead of generating pseudo-markup for interactions. This might be able to better handle the larger list since it wouldn't duplicate it. We'd still have to handle 2000ish elements at once in this case.