Correction for Drop CSTM80

[rallyrabbit]

Problem:
Drop CSTM80 laid out the LED definitions but laid in them out in logical hardware order. This caused problems in two areas:

1. Users wanting to create custom keymaps while depending on the stock driver had no way to overcome the hardware order defined when needing LEDs in logical key map order. 2) RGB effects that were row defined for specific patterns were always off as traversing the LED definitions was always off.

Description

Solutions
The LED hardware array definitions are now laid out in row order, matching the key switch order in the driver.

Types of Changes

• Core
• [ X ] Bugfix
• New feature
• Enhancement/optimization
• [ X ] Keyboard (addition or update)
• Keymap/layout (addition or update)
• 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.
• My change requires a change to the documentation.
• 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).

[zvecr]

This breaks the mapping of key to LED, meaning that reactive effects are now completely incorrect, as well as any position based effect rendered incorrectly too.

[rallyrabbit]

All right, I follow, what's the solution then, I see now where it breaks the reactive effects, but it also makes it next to impossible to lay out a logical keymapping to get a logically mapped overlay of function keys to keys to be mapped. Previous drop drivers had this mapped really well, until this one.