Allow QMK to save a single default layers in the full range of 0-31

[infinityis]

Description

Currently QMK saves the default layer persistently through EECONFIG as an 8-bit wide bit field which allows for saving multiple simultaneous default layers, but only for layers 0 through 7. This PR adds the ability to save the default layer as a value instead of a bit field, so that layers 0 through 31 can be the default layer, subject to the constraint that there is only one default layer selected at a time.

Pull request https://github.com/qmk/qmk_firmware/pull/21881 is written to allow default layers in the range from 0 to 31, but that is currently not possible with the existing implementation. Functions like set_single_persistent_default_layer indicate that the more common use case is a single default layer. There are no instances of multiple default layers being saved in the QMK repository, but there is awareness of one instance of multiple default layers being used in the recently removed user code.

This PR changes the default/presumed paradigm to a single default layer, and the original bit field method can be the re-enabled with #define DEFAULT_LAYER_BITMASK_ENABLE. If desired, I can update the PR to preserve the original implementation by default instead.

Additionally:

• ~~All bespoke implementations that save default layers by calling eeconfig_update_default_layer to set a single layer have been replaced with API calls to set_single_persistent_default_layer~~ Removed from this PR, was implemented in #23436
• ~~EECONFIG magic number has been decremented~~ No longer decremented as a decrement has already been performed for this breaking chances cycle

Types of Changes

• [X] Core
• [ ] Bugfix
• [X] New feature
• [X] Enhancement/optimization
• [ ] Keyboard (addition or update)
• [ ] Keymap/layout/userspace (addition or update)
• [X] Documentation

Issues Fixed or Closed by This PR

Checklist

• [x] My code follows the code style of this project: C, Python
• [x] I have read the PR Checklist document and have made the appropriate changes.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.
• [x] I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[github-actions[bot]]

Thank you for your contribution! This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready. For maintainers: Please label with bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[infinityis]

Rebased on develop after merge of #23436 which implemented all the keymap cleanup changes; what remains of this PR is much smaller and focused on the primary goal of changing how eeconfig saves the default layer information.

I'm not sure if EECONFIG_MAGIC_NUMBER should decremented once per breaking changes release, or if it is decremented anytime a change is made to eeconfig storage implementation (in which case I would need to add in another decrement).

[tzarc]

There's a bit of debate internally as to whether or not we should reshuffle the eeconfig definitions and allow for auint32_t here. Will get back to you.

[github-actions[bot]]

Thank you for your contribution! This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready. For maintainers: Please label with bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[github-actions[bot]]

Thank you for your contribution! This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready. For maintainers: Please label with bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.