Sync Timer feature

[XScorpion2]

Description

Added a sync_timer set of apis that will keep their value in sync across split common keyboards. This helps keeps led animation effects in sync when run in split modes (RGBLIGHT_SPLIT or the upcoming RGB_MATRIX_SPLIT). This PR is targeting the development branch as this is a change to the Transport code which will require users to flash both master and slave halves.

Spent quite a bit of time poking at RGBLIGHT fixing the hitching of the previous attempts at a sync timer. Solved all the hitching, but it still does not stay in sync as well as I would like (when RGBLIGHT_SPLIT_NO_ANIMATION_SYNC is defined) due to how animation ticks are handled in RGBLIGHT. So while it's using the sync timer, it's not any better than what it was before. Additionally an option to disable the sync timer and fall back to normal timer is possible using the #define DISABLE_SYNC_TIMER

All hitching for RGBLIGHT with sync_timer has been fixed. Additionally RGBLIGHT now stays in sync with RGBLIGHT_SPLIT_NO_ANIMATION_SYNC defined Only remaining issue: boot / startup time hitching causes the animations to start out of sync. So there needs to be an initial sync event to get them lined up. RGBLIGHT_SPLIT_NO_ANIMATION_SYNC not defined still fixes this.

Note: In testing, this was used in conjunction with #10996

Types of Changes

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

Issues Fixed or Closed by This PR

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).

[fauxpark]

Could you also do a qmk cformat pass?

[XScorpion2]

Could you also do a qmk cformat pass?

Nope, because the qmk cli doesn't work for me:

$ qmk cformat
ERROR: It seems you are not using the MINGW64 terminal.
Please close this terminal and open a new MSYS2 MinGW 64-bit terminal.
Python: /usr/bin/python, MSYSTEM: MINGW64

This was after attempts to reinstall, and fight Kaspersky constantly flagging the installer as a virus. I ran the clang formatter in visual studio at least.

[fauxpark]

It should be running in the MinGW64 Python, not MSYS (ie. /mingw64/bin/python). My guess is you have installed the CLI though the MSYS pip. The simplest and most reliable solution would be to nuke the C:\msys64 folder and start again, but you could also try to python3 -m pip uninstall qmk inside an MSYS terminal, then:

pacman -S mingw-w64-x86_64-python-pip
python3 -m pip install qmk

in the MINGW64 terminal.

[XScorpion2]

QMK cli was installed from the MINGW64 terminal, I never use the other versions of the terminal. Will try the nuke and reinstall approach.

[XScorpion2]

@fauxpark fought quite a bit with the qmk cli setup process. Finally got it working and ran the cformat against the touched pr files and checked in the results.

[XScorpion2]

rebased & force push