Fixes potential wpm sampling overflow, along with code comment fixes

[vectorstorm]

Further WPM feature cleanup

This commit does some further cleanup on the WPM feature as modified as part of pull request #13902 .

There are four main changes here:

1. Increased the size of sampling buffers from 8-bits to 16-bits, to dramatically reduce the chances of overflowing the integers.
2. Dropped the default number of WPM sampling buffers from 50 to 25, to compensate for the increased size of the sampling buffers. This change includes editing the documentation file feature_wpm.md to bring it up to date with the changed default value.
3. Added some safety code to explicitly verify that no matter what, we won't overflow beyond either the high or low limits of the 16-bit signed integers.
4. Fixed a subtle (minor) bug which could happen if both WPM_LAUNCH_CONTROL and WPM_ALLOW_COUNT_REGRESSION were enabled. In that case, if you typed some characters in one sample buffer and then backspaced over them in another sample buffer, launch control would re-arm but would also be giving you wpm credit for those first characters you typed, as if you hadn't backspaced over them. Now those are cleared out to always properly re-zero your WPM while launch control is re-armed.
5. Moved around and consolidated a number of #if defined statements to reduce the number of ifdef blocks overall in the code, and converted all of them to #if defined instead of #ifdef, just for consistency's sake. Similarly, flipped around the code blocks in a couple cases of #ifndef #else #endif so they'd be #if defined() #else #endif, for future ease of reading/understanding.

Types of Changes

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

Checklist

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

[vectorstorm]

And since I didn't mention it above..

Testing a build of my custom keymap using this version of the wpm code vs. the previous version of the wpm code, under this commit we're using 36 extra bytes of firmware. (26838 with the new code vs 26802 with current 'develop'). That's with every optional feature enabled (including 'unfiltered').

Of those bytes, 28 of the extra bytes are due to moving up to 16-bit integers instead of 8-bit ones for the WPM feature's ring buffer storage. From the AVR manuals it appears that it only natively does arithmetic on 8-bit values, so it requires more assembly instructions to do arithmetic on 16-bit integers; that's where the bulk of the extra firmware space is coming from.

So the question is this: is it worth spending 28 bytes of firmware storage to store data in 16-bit integers instead of 8-bit ones? We can get all of that space back by reverting to 8-bit integer storage, and maybe that'll be okay now that we're guarding against overflow explicitly and won't have those rare wrap-around problems we currently (theoretically) have in 'develop'.

(side-note: finally having read some guides to AVR ASM has made so much about its firmware sizes make so much more sense to me than it ever did before)