…#5839)

* Add test to ensure search autocomplete attribute is set

This adds a basic test to make sure that the `autocomplete` attribute
on the search box is set based on the value of the `autocomplete`
option that is passed in to Select2. This alows people to set the
`autocomplete` attribute on their `<select>`, which is valid
according to the spec, and have it copy over to the search box of
their Select2 instance.

* Add tests for options set by HTML atttributes

This adds some missing tests for the disabled and multiple attributes
and how they can be used to set the corresponding options within
Select2. This also adds tests for the new autocomplete option that
ensures it is properly synchronized based on the attribute being
set.

* Add support for the autocomplete attribute

This will now copy the `autocomplete` attribute (based on the current
state of the `autocomplete` DOM property) from the `<select>` to
any search boxes that are used by Select2. This is necessary to
both handle cases where people do not want the autocomplete
disabled, as well as handling cases where people are looking to set
a custom autocomplete which will assist users when searching.

This still maintains backwards compatibility with the `autocomplete`
option being set to `off` by default. It also allows the
`autocomplete` option to be set through the standard Select2 options
to override the `autocomplete` attribute if it is present.

This does not follow the precedent set by the `disabled` and `multiple`
options where the value is synchronized back to the original
`<select>` when it is overridden by the options. This is because it
would break backwards compatibility because the default state of
the `autocomplete` property is a blank string ('') instead of `off`
which is what Select2 uses.

* Skip autocomplete attr test when not supported

Not all browsers, including older version of PhantomJS, support
the `autocomplete` attribute when it is set on a `<select>` element.

This changes the internal generation of the ID used to uniquely
identify an element to be more resistant to collisions. Previously
it was an incremented integer or the exact ID used on the element,
which for most cases was unique enough. Unfortunately if any elements
used by Select2 also had an ID that was a low number, it was almost
guaranteed to collide with an internal ID that Select2 generated.

The internal generation now relies on a prefix when the ID already
exists, similar to what we do with core IDs. It also uses a set of
4 random characters along with the incrementing ID to reduce the
chance of collisions even further.

It is definitely still possible for a collision to occur, especially
if two elements exist but one has a prefix of `data-` already, but
the chances have been greatly reduced. We'll accept it for now.

* Switch CSS to use BEM over attribute selectors

Previously the CSS was using a combination of very specific BEM
class selectors and attribue selectors based off of ARIA attributes
that were expected to be present on the elements. This creates odd
specificity battles that people have been complaining about for
years, so now we're solving a few of the issues by switching to
BEM classes instead of using the mix.

This is a breaking change within any applications that override
the Select2 CSS through creating higher specificity selectors. While
the attributes are still present on the elements, we are no longer
going to be treating adjustements to them as breaking changes. This
is important becuase accessibility is a changing field and we know
we are going to have to make adjustments going forward.

* Mark highlighted results with aria-selected

This is a breaking change from past expectations where the options
within the results that were selected within the dataset were
previously marked as `aria-selected=true`.

When Select2 was first implementing the `aria-selected` attribute,
the interpretation that we followed was that the "selected" state
was supposed to represent the idea that the option was "selected"
similar to what is done within a standard dropdown. This would make
sense and would align with the interpretation of the WAI-ARIA
Authoring Practices 1.0 where it explicitly says that it represents
the selected state of the option. We later found out, after Select2
had been released, that this intepretation was incorrect and the
large majority of assistive technologies did not align with this
interpretation.

The `aria-selected` attribute should represent the location of
focus within the component. This allows screen readers to read the
contents out load and also detect changes within the focus location.
In later revisions of the WAI-ARIA spec, this was made more clear
that the `aria-selected` attribute forces the focus to be moved to
the element containing that attribute, which is in line with the
behaviour that was encountered during testing.

This should fix a bug that has been around for a while where using
VoiceOver in the Safari browser would result in the currently
focused option not being read aloud.

* Fix failing test

There was a test which was checking the selected status of an option
based on the `aria-selected` attribute. Instead this has been
switched over to check to make sure the new class is not present.

* 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

There was a bug in the 4.1.0-beta.0 release which resulted in the
`selectionCssClass` not being functional. This was because the
defaults had not been updated to support this option despite the
documentation and the release notes claiming it was supported.

This switches the Bootstrap theme recommendation over to the much
newer and much more maintained Bootstrap 4 theme.

[Release] 4.1.0 beta.1