feat(BCheckbox)!: Implement reverse and without label

[dwgray]

Describe the PR

Implement the reverse and without-label features of checkboxes and radio buttons.

Reverse is implemented as a property on BFormCheckbox and BFormCheckboxGroup
Without Labels is implemented by not including the form-checkbox class when there is no default slot

In addition:

• Implemented and tested the same properties in BFormRadio and BFormRadioGroup
• Updated the documentation for BFromCheckbox and BFGormCheckboxGroup
• Made scope option in the ComponentReference data (because it is)
• Removed input and change events from BFormCheckboxGroup - these events were removed from BFromCheckbox in fix(): Remove @input in favor of @update:modelValue #1696 so it doesn't seem like it makes sense to keep them in the group.

I believe that this PR brings us to parity with BSV legacy and BS5. There is some more clean-up to do with BFormRadio, I didn't intend to touch that at all, but since there was a shared component I did the minimum to get the core feature I was working on to work with Radio controls.

Small replication

A small replication or video walkthrough can help demonstrate the changes made. This is optional, but can help observe the intended changes. A mentioned issue that contains a replication also works.

PR checklist

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

• Bugfix 🐛 - fix(...)
• Feature - feat(...)
• ARIA accessibility - fix(...)
• Documentation update - docs(...)
• Other (please describe)

The PR fulfills these requirements:

• Pull request title and all commits follow the Conventional Commits convention or has an override in this pull request body This is very important, as the CHANGELOG is generated from these messages, and determines the next version type. Pull requests that do not follow conventional commits or do not have an override will be denied

BREAKINGCHANGE: BFormCheckboxGroup and BFormRadioGroup no longer emit input or change events - please use update:modelValue instead

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[dwgray]

@VividLemon I wasn't comfortable (or even sure it would work) doing a forced push to my branch to amend the commit messages that included the breaking change, so this is a new PR that includes the changes that you requested int #1823. The code changes are all in the most recent commit to update BFormRadioGroup and I amended the commit message for the BFormCheckboxGroup to include the ! and BREAKINGCHANGE footer. Sorry, I missed this originally, but the changes that removed those events from BFormCheckbox and BFormRadio didn't include a breaking change notice

[VividLemon]

@VividLemon I wasn't comfortable (or even sure it would work) doing a forced push to my branch to amend the commit messages that included the breaking change, so this is a new PR that includes the changes that you requested int #1823. The code changes are all in the most recent commit to update BFormRadioGroup and I amended the commit message for the BFormCheckboxGroup to include the ! and BREAKINGCHANGE footer. Sorry, I missed this originally, but the changes that removed those events from BFormCheckbox and BFormRadio didn't include a breaking change notice

It doesn't really matter how you add commits to a PR, as I will squash merge them into one commit to preserve a linear history anyways. For example, one could have just as easily done git commit --allow-empty -m "" to add it. But I suppose this would require the knowledge that I intended to squash merge the commits

[dwgray]

@VividLemon I wasn't comfortable (or even sure it would work) doing a forced push to my branch to amend the commit messages that included the breaking change, so this is a new PR that includes the changes that you requested int #1823. The code changes are all in the most recent commit to update BFormRadioGroup and I amended the commit message for the BFormCheckboxGroup to include the ! and BREAKINGCHANGE footer. Sorry, I missed this originally, but the changes that removed those events from BFormCheckbox and BFormRadio didn't include a breaking change notice

It doesn't really matter how you add commits to a PR, as I will squash merge them into one commit to preserve a linear history anyways. For example, one could have just as easily done git commit --allow-empty -m "" to add it. But I suppose this would require the knowledge that I intended to squash merge the commits

Good to know - do you generally squash merge commits? So if I had just made the change to BFormOptionGroup and fixed the title of the PR (which would be the default title for the squashed commit if I read this correctly, would that have addressed your original comment?

Not complaining - it was useful for me to figure out interactive rebasing in git, just want to make this smoother in the future...

[VividLemon]

@VividLemon I wasn't comfortable (or even sure it would work) doing a forced push to my branch to amend the commit messages that included the breaking change, so this is a new PR that includes the changes that you requested int #1823. The code changes are all in the most recent commit to update BFormRadioGroup and I amended the commit message for the BFormCheckboxGroup to include the ! and BREAKINGCHANGE footer. Sorry, I missed this originally, but the changes that removed those events from BFormCheckbox and BFormRadio didn't include a breaking change notice

It doesn't really matter how you add commits to a PR, as I will squash merge them into one commit to preserve a linear history anyways. For example, one could have just as easily done git commit --allow-empty -m "" to add it. But I suppose this would require the knowledge that I intended to squash merge the commits

Good to know - do you generally squash merge commits? So if I had just made the change to BFormOptionGroup and fixed the title of the PR (which would be the default title for the squashed commit if I read this correctly, would that have addressed your original comment?

Not complaining - it was useful for me to figure out interactive rebasing in git, just want to make this smoother in the future...

if the commits == 1 then I rebase, if commits > 1 I squash, always. The long running branch is an issue for those using the same branch. Typically me with using a single main branch. I always run into this issue. But to fix this I either A: fix the commits with ANOTHER SQUASH MERGE! or git reset --hard ${commit_hash} (before making any changes locally. You'll destroy your staged and unstaged local changes if you do that) or the issue can be avoided with using a different branch per change