* Move selection search out of list

The selection search was previously being injected into the list of
selections. This was largely done because it was easier to style
and it matched up wiht how we injected the search box in older
version of Select2. Unfortunately it was pointed out to us that
this breaks the semantics of the list of selections, which is
definitely accurate and impacts accessibility.

The search box for selections, used primarily in multiple selects,
was moved to be next to the list of selections. Functionally, this
does not impact Select2 at all because of how we manage focus, but
it does impact the accessibility and styling of Select2. This moves
closer to bringing the Select2 selection area for multiple selects
into an accessible state, by pushing for the selections (the options
that were previously selected) to be within their own container and
to not interfere with other elements that may be present. This is
important because screen readers need to be able to read the current
selections and differentiate between elments.

This impacts the styling of Select2 internally, without impacting
how it visually looks to our users. We have switched from floating
all of the options to keep them visually in line to using a set of
inline-block elements that better reflect what is actually happening.
As a result, the base stylng as well as the styling for the default
and classic themes has been adjusted to use a set of inline-block
elements while maintaining any spacing between elements that
previously existed. Because the DOM ordering has changed, anyone
who was relying on DOM order instead of classes for styling the
search box will need to update their CSS to reflect the new
ordering. The same applies to any plugins which were relying on the
DOM to be stable in order to make changes.

This also switches the selection search to take up the full width
of the container when the placeholder is visible. This fixes a
long-standing issue where it was possible for the placeholder on
a multiple select to be hidden depending on the state of the DOM
at the time the placeholder was rendered.

* Moved clear button out of rendered selection

The clear button was previously being injected at the start of the
rendered selection, creating invalid markup on multiple selects
where the rendered selection is a list, and overloading what the
rendered selection was for in single selects. It has now been moved
out of the rendered selection and it is now in front of the rendered
areas, allowing the clear button to still be floated to the right
over the rendered selection itself.

The clear button has also been changed to use a `<button>` element,
though it is still removed from the tab order. This allows for the
purpose to be properly communicated to screen readers while not
disrupting the natural tab order of the select box.

This affected the CSS across all themes because the positioning is
affected now that it is not located within the rendered container.
This required some small ajustments to get it to appear alongside
of the arrow within single select boxxes. This also required some
adjustments in order to get it to appear in the right location and
affect the rendering order within multiple selects, where the clear
button should push the search and selected choices down and around
it instead of appearing directly over it.

Because of the change to a `<button>` element, the clear icon may
render differently for some users because of the default stylesheet
rules. This may also come into play within themes where the `<button>`
elements may be styled differently.

* Add aria-describedby to selection search

This should make it more clear now what the current selections are
when the selection search is being used. In the future we may switch
this to pointing at a dedicated element which handles the accessibility
text representing the current selections, but for now we will rely
on the rendered selection to do the job.

* Set `type=button` on the "clear all" button

This will ensure that when the button is clicked, any form that the
select is contained within is not triggered. This is because buttons
default to `type=submit` within forms.

* Render choices inside additional span

This additional span is now being given a unique ID, similar to the
one which is given each result in the dropdown, and it is being
associated with the corresonding remove button for that choice. This
should not affect the rendering of the individual choices but it
does allow us to move forward on fixing accessibility issues around
the remove icon within multiple selects. Now when a remove icon is
focused by a screen reader, it should read out the text of the option
that would be removed.

* Make the remove item button an actual button

This moves the remove item icon from being a span that can be clicked
to being an actual button that acts and behaves like a real button.
This means it is now using a `<button>` element and can receive
keyboard events to trigger the removal of an item, as well as the
mouse events it could previously receive.

Because the selection area can receive keyboard events that behave
differently from the removal of an item, a new handler needed to be
added for the remove button that stops the propagation of keyboard
events for it. This allows the enter key to propagate like it would
previously and trigger the click event.

This required some heavy adjustments to the CSS that will affects
themes. the click area for the remove item button is now larger and
visaully is separated from the text of the item itself. The
separation is done by a solid line to the right of the button which
can be removed by CSS if the user desires. The background of the
remove item button also visually changes now when the button is
hovered or focused, instead of before where it was only the text
color that changed. The classic theme does not incorporate most of
these changes.

This also updates the RTL theme to work with all of the styling
changes that have been made so far.

* Add aria-describedby to clear button

The clear button currently says "Remove all items" but it does not
provide any context to screen readers what items will be removed.
By adding the `aria-describedby` attribute, they will now announce
the selected options after annoying that the button is to remove
all items.

* Hide the "x" in the remove icons from screen readers

Previously screen readers would hear the "x" be read aloud within
the different clear/remove icons even though it does not serve an
actual purpose for them. This hides them so now it should only read
out the label and that's it.

* Add helper text for the remove item button

This adds a title and aria-label attribute for the remove item
button. This should ensure that screen readers read out "Remove item"
followed by the item text when these icons are focused. This adds
a new translation for this text, but translations for languages
other than English will need to be added separately.

* Add aria-label for remove all button