`aria-haspopup` use requires the use of an ARIA `menu`, `listbox`, `tree`, `grid` or `dialog` (see https://www.w3.org/TR/wai-aria-1.1/#aria-haspopup)
in our use (as generic disclosure widgets), it's incorrect and sets up the wrong assumption/behavior from assistive technologies.
in future, we likely want to change our dropdowns to essentially be like a `dialog` - move focus to it when opened, possibly make it modal so focus is maintained inside it and the rest of the page
is hidden/inert.
but for now, removing the incorrect attribute is probably the quickest, most immediate fix.
- Move 4.1 docs to 4.2
- Update versions everywhere to 4.1.3 with release script
- Manually bump the shorthand version in package.json
- Add 4.2 to the versions docs page
- Update some redirects
- Fix tests asset URLs
- Bump Nuget and more
* Remove IE compatibility mode meta tag from docs, examples, and JS tests as we no longer support IE9 and IE8
* update and remove some IE bits from our supported browser page
* update introduction.md to match
* reword starter template intro
as role="menu" is a very specific (and strict) ARIA pattern for
desktop-like application menus, and our dropdowns are often used
as pure navigation dropdowns, this change abandons ARIA menus for
a more open-ended and light-weight approach
(see http://heydonworks.com/practical_aria_examples/#submenus and
http://www.w3.org/WAI/tutorials/menus/flyout/#improve-screen-reader-support-using-wai-aria)
note that in dropdown.js, switched to now target ``.dropdown-menu``
instead of ``role["menu"]`` - this also prevents bootstrap scripts
from "bleeding" into non-bootstrap components on the same page.
also removed the ``role=["listbox"]`` part, which appears to be
vestigial/unused (only place in bootstrap that uses that
role are carousels, and their key handling is done separately)
