Describe the PR

Creates table child element helper components, which will be used internally by <b-table> and <b-table-lite>, and can be used directly by consumers when using <b-table-simple>. or in the slots top-row, bottom-row and thead-top

The helper components simplify handling row and cell variants, as well as providing accessible aria roles, scopes, and other aria-* attributes. role and scope and some aria-* can be overridden if the users set the attributes on the component.

The child components receive injections from the parent components for feature sniffing and detection.

Generated accessibility markup is improved via automated roles and scope attribute generation.

Additional features:

• Added in table-variant support, to colorize the table with one of the theme colors. This feature was available before by manually placing a table-* or bg-* variant class on the table root element. The new table-variant prop simplifies this, and automatically adjusts to which variant class prefix to use, based on the tables dark mode.
• Added in support for sorting null/undefined/empty-string last via the new sort-null-last prop. By default null/undefined/empty-string are considered less than any other value. setting this pro to true makes them appear greater than any other value. (closes Return empty values last in table sorting #3816)

New child components:

• b-td - functional wrapper for private helper component BTableCell
• b-th - functional wrapper private helper component BTableCell
• b-tr
• b-thead
• b-tbody
• b-tfoot

To Do:

• convert helper mixins use new child helper components
• documentation updates, new examples
• unit tests (if required, as new child components will be used by b-table, which has tests checking for child elements)
• update top-level named exports of new components
• update TypeScript declaration with the new components

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 / optimization

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)