Allow disabling RGB_MATRIX_ANIMATIONS on system76 keyboards with a pre-procesor directive

[PeterFalken]

Description

Allow disabling RGB_MATRIX_ANIMATIONS on system76 keyboards by using a pre-procesor directive.
Not defining the animations can free up storage space (~2.2KB or more on atmega32u4) to use on other features. When DISABLE_RGB_MATRIX_ANIMATIONS is not defined, the default behavior is unchanged - It's intended to be minimally invasive and straight forward.

This change can be activated on a custom keymap with the following code:

#define DISABLE_RGB_MATRIX_ANIMATIONS
#undef ENABLE_RGB_MATRIX_CYCLE_ALL
#undef ENABLE_RGB_MATRIX_CYCLE_LEFT_RIGHT
#undef ENABLE_RGB_MATRIX_CYCLE_UP_DOWN
...

An example of how it can be used on a keymap file can be found here.

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

[leviport]

(not sure if I should leave reviews on upstream QMK, but I wanted to share my findings)

I ran a few tests, building launch_1 firmware with the config.h file you linked, both with #define DISABLE_RGB_MATRIX_ANIMATIONS and the 11 #undef's below it, and with all of those lines commented out.

With animations disabled, the built firmware was 20174/28672 bytes. With animations enabled, the size was 22454/28672, meaning that disabling animations frees up 2280 bytes. My launch_1 is still working fine with animations disabled, and so does the non-RGB animation functionality of system76-keyboard-configurator. The configurator also still allows me to set solid colors per-layer, just none of the included animations. I assume users that build their own firmware and intentionally disable animations would not be confused by that feature in the configurator not working afterwards. So, I think this change looks good!

[PeterFalken]

Thank you @leviport, for the feedback and testing - I really appreciate it.
Updated the comment for the PR to reference 2.2KB, the extra space I noticed is probably associated with other features I had disabled on my configurations.