Description of Pull Request:

• Probes this.$slots.default to determine render order of child tab components (as this.$children doesn't guarantee node order)
• Add lazy prop to b-tab, to allow individual tabs to be lazy rendered (b-tabs lazy prop takes precedence if true). a lazy tab will not render its default slot when not active but the b-tab wrapper elements will always be rendered to allow for transitions to work correctly.
• Better reactivity of tab title slot
• Better reactivity of tab title prop
• Switches to provide and inject, rather than using this.$parent for parent-child communication.
• Add activate() public method to b-tab component (if tab isn't disabled, it will set this tab as active)
• Add deactivate() public method to b-tab component (deactivating will activate the first non-disabled tab)
• handles b-tab being dynamically disabled after mount
• Switch to roving tabindex method for keynav
• Better ARIA compliance when keynav enabled, by adding tabindex="0" to the active tab so that screen reader users can focus the actively disaplayed tab so that it can be read by screen readers.
• Additional units tests

Fixes: #2327
Fixes: #2148
Closes: #2403
Closes: #2180

Users (web authors) must also realize that tabs' controls are (or act like) buttons. One cannot place form controls inside a button/link per HTML/HTML5 standards. Stop trying to do this! 😝

PR checklist:

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Enhancement to an existing feature
• ARIA accessibility
• Documentation update
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes
• No

If yes, please describe the impact:

The PR fulfills these requirements:

• It's submitted to the dev branch, not the master branch
• When resolving a specific issue, it's referenced in the PR's title (i.e. fixes #xxxx[,#xxxx], where "xxxx" is the issue number)
• The PR should address only one issue or feature. If adding multiple features or fixing a bug and adding a new feature, break them into separate PRs if at all possible.
• PR titles should following the Conventional Commits naming convention (i.e. "fix(alert): not alerting during SSR render", "docs(badge): Updated pill examples, fix typos", "chore: fix typo in docs", etc). This is very important, as the CHANGELOG is generated from these messages.

If new features/enhancement/fixes are added or changed:

• Includes documentation updates (including updating the component's package.json for slot and event changes)
• New/updated tests are included and passing (if required)
• Existing test suites are passing
• The changes have not impacted the functionality of other components or directives
• ARIA Accessibility has been taken into consideration (does it affect screen reader users or keyboard only users? clickable items should be in the tab index, etc)

If adding a new feature, or changing the functionality of an existing feature, the PR's description above includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)