manual backport of #34886

per https://www.w3.org/TR/html-aria/#docconformance

> It is NOT RECOMMENDED to use `aria-disabled="true"` on an `a` element with an `href` attribute.
>
>NOTE
>If a link needs to be "disabled", remove the `href` attribute.

This PR removes the unnecessary `href="#"`, `tabindex="-1"`, and `aria-disabled="true"` from disabled links in both docs pages and examples. `aria-disabled="true"` *is* kept for disabled link-based buttons (that have `role="button"`) as there it's appropriate to use (you *want* to convey to assistive technologies that this thing you're claiming is a button is also disabled at the moment)

Further, the PR extends the "Link functionality caveat" to show the "proper" way (removing `href` and adding `.disabled` class only) to disable a link, but then explains what to do if that's not possible (and then keeps an example with all the traditional `href="#" tabindex="-1" aria-disabled="true"`, but explains clearly that it's not ideal). Same sort of explanation is also added to the pointer event utilities page

`aria-haspopup="true"` is really intended to signal that an ARIA `menu` will be opened on activation. as a result, some assistive technologies will announce controls with `aria-haspopup="true"` as a menu or menu item (e.g. JAWS and NVDA).
In addition, `aria-haspopup` seems to trigger a bug in Edge/Narrator where the `aria-expanded` state is not correctly announced at the moment when `aria-haspopup` is present.
This now makes the dropdown button more like a generic disclosure widget control - see also https://www.w3.org/TR/wai-aria-practices-1.2/examples/disclosure/disclosure-navigation.html01

* Bump version to v4.6.0.

* Dist

While technically it still works, we're already saying authors shouldn't do it later on, and we removed any examples of this. This was a straggler.

Co-authored-by: XhmikosR <xhmikosr@gmail.com>

v4 backport: Replace Lorem Ipsum placeholder text with more representative (or at least english language) text (#32462)

Backport and expansion (for v4) of #32246 and #32479

docs: use `event` instead of `e`

This commit includes all the needed workarounds and most changes from the main branch for everything to work, like:

* removing empty lines in raw HTML that break output
* read .browserslistrc, CSS variables from disk instead of duplicating it
* using Hugo mounts
* using Hugo for the docs CSS/JS
* move ToC Sass code to a separate file while adapting it for Hugo

Thus, this patch makes our npm scripts faster since lint runs on one step and there's no separate docs assets processing.

Remove the class `.nav-item` from `.nav-link` inside the non `ul` or `ol` based navs.
This makes the consistency for `.nav-item` (This class will not be required on the `.nav-link`).
`.nav-item` was only required when you use `.nav-fill` or `.nav-justified` on the `.nav`. In other cases, it was redundant. And the purpose of `.nav-item` on `.nav-link`s can be achieved via flexbox utilities as well (Mentioned in the docs also).

Add aria-role presentation on li element when ul element has role tablist and remove dropdown from visual tests as they've been removed from doc

* Prep for v4.3.0

* More updates for v4.3.0.

* rerun to build docs source map

- 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

Add `tabindex="-1"` and `aria-disabled="true"` to disabled link

With the current docs directory setup, I'm making too many mistakes and have to manually address path changes and directory moves on deploy. This makes for a frustrating experience developing locally and shipping releases. With this PR, we're basically back to the same setup from v3—duplicating the dist directory into our docs directory. Not the most ideal, but very straightforward for me as the release manager.

* update docs path from docs/4.0/ to docs/4.1/

* bump version to 4.1.0

* Update redirects to work for 4.1 docs move

* Update docs version switcher to include latest and link to 4.0 docs

* re-run dist

* Update package-lock.json

* Update docs-navbar.html

Add the column/grid to the example code (which is what makes it vertical in the first place)

* Add dispose methods in our documentation

* Update buttons.md

* Use `aria-selected` instead of `aria-expanded`
* Change tab.js to use `aria-selected` rather than `aria-expanded`
* Add `aria-orientation=vertical` to vertical tab list
* Remove dynamic tabs with dropdowns
* Fix non-interactive code examples
* Only set `aria-selected` on the `role="tab"` trigger - this stops `aria-selected` being incorrectly added to the `role="tabpanel"` itself (probably harmless, but nonetheless incorrect)

Fixes #20660

* Split out/expand mention that base navs lack active styles
* Add accessibility notes for navigation bars vs dynamic tabbed interfaces

* Fix incorrect code indentation
* Remove unnecessary vendor prefix for `box-sizing` - all modern browsers now support this unprefixed
* Remove incorrect `<label>` and change static controls to readonly inputs
* Allow `<img>` elements without `src` to allow for `holder.js` images used in the docs, which lack `src` and use `data-src` instead