Describe the PR

Complete refactor of tooltip and popover code to be more "Vue" like (less direct DOM manipulations, and no longer a direct port of Bootstrap v4.3 code), more modular, and more reactive.

Clears up many issues with tooltips and popovers

Notable improvements:

• Component versions now render only a comment placeholder node in the DOM (instead of a DIV), so that app layout is never affected (i.e. component version can be placed directly inside input groups, etc)
• variant and custom-class are reactive and can be changed while tooltip is open
• custom-class can now be a scoped style, but note that one still needs the vue-loader /deep/ selector to target the inner elements of the tooltip or popover.
• Directive versions are now reactive to title attribute changes and config option changes while the tooltip or popover is open
• Triggers setting is now reactive. they can be changed while the tooltip is open
• Show/hide delays for Tooltip and Popover are now defaulted to 50ms (delays are applicable for hover and focus only), which will help reduce "spastic" tooltips/popovers.
• It is now possible to specify hide and show delays individually on directive versions via modifiers
• It is now possible to set triggers to 'manual' which allows only programmatic showing/hiding of tooltips and popovers
• When trigger is 'hover' (or 'focus'), one can now move the mouse over (or move focus to) the tooltip/popover and it will remain open
• Popovers with slot content do not "breakup" when quickly hovering/un-hovering
• User can now optionally supply their own ID to be used on the tooltip/popover root element. If an ID is not provided, an ID will automatically be added (default behaviour).
• If a tooltip or popover is given an ID, $root events can use this ID to open/close/enable/disable the tooltip/popover. Use of the trigger element's ID works as well.

Note:

• Tooltips an popovers now use a bit of custom SCSS to make the Bootstrap v4.3 transitions work better with Vue's <transition> component. Previously tooltips and popovers could not take advantage of Vue's <transition> component. The use of the <transition> component has greatly reduced the lines of code required, at the expense of a few new lines of custom SCSS.

Fixes #1990
Fixes #2937
Fixes #3480
Fixes #3717
Fixes #3854

Closes #3451
Closes #2261

TODO:

• Change component b-tooltip to use new instances
• Change component b-popover to use new instances
• Change directive v-b-tooltip to use new instances
• Change directive v-b-popover to use new instances
• Tooltip/Popover without any triggers for programmatic showing/hiding only (Closes Create a tooltip without UI triggers #3451)
• Update test suites (add reactive title/content/variant/custom-class tests)
• Docs update

PR checklist

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

• Bugfix
• Feature
• Enhancement
• ARIA accessibility
• Documentation update
• Other (please describe) Code refactor

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

• No
• Yes (please describe)

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 #xxx[,#xxx]), where "xxx" is the issue number)
• It 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.
• The title should follow the Conventional Commits naming convention (i.e. fix(alert): not alerting during SSR render, docs(badge): update pill examples, fix typos, chore: fix typo in README, 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)
• Includes any needed TypeScript declaration file updates
• 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)