Helix add split common option

[MakotoKurauchi]

Description

This PR adds the option to use split_common for Helix keyboard compilation.

• Compiling as follows will compile with the current Helix custom code.

  make helix:default
  make helix/pico:default
  

• Compiling as follows will compile with split_common code.

  make helix/rev2/sc:default
  make helix/pico/sc:default
  

You can also specify the use of split_common by adding the following in rules.mk for each keymap:

SPLIT_KEYBOARD = yes

All keymaps have been tested and verified to work.

What is split_common different from current Helix custom code

• Due to the current limitation of split_common, the current layer information cannot be obtained on the slave side, so the layer information cannot be displayed correctly on OLED etc.

• split_common scans the matrix a bit slower.

  	scan cycle/second
  Helix custom code	1590
  split_common	1190

Keymaps source file compatibility

All keymaps 'keymap.c' and 'config.h' are unchanged. There is no need to change.
The 'rules.mk' of all keymaps except 'xulkal' have not changed.

In the 'xulkal' keymap rules.mk, SPLIT_KEYBOARD = yes was added to always use the split_common code, and the following code in 'users/xulkal/custom_oled.c' was removed.

#if KEYBOARD_helix_rev2
extern uint8_t is_master;
bool is_keyboard_master(void) { return is_master; }
#endif

All compile option patterns

• build helix/pico (HelixPico) with helix current codes

  $ make helix/pico:KEY_MAP
  $ make helix/pico/back:KEY_MAP
  $ make helix/pico/under:KEY_MAP
  

• build helix/rev2 (Helix or Helix beta) with helix current codes

  $ make helix:KEY_MAP
  $ make helix/rev2/back:KEY_MAP
  $ make helix/rev2/under:KEY_MAP
  $ make helix/rev2/oled:KEY_MAP
  $ make helix/rev2/oled/back:KEY_MAP
  $ make helix/rev2/oled/under:KEY_MAP
  

• build helix/pico (HelixPico) with split_common codes

  $ make helix/pico/sc:KEY_MAP
  $ make helix/pico/sc/back:KEY_MAP
  $ make helix/pico/sc/under:KEY_MAP
  

• build helix/rev2 (Helix) with split_common codes

  $ make helix/rev2/sc:KEY_MAP
  $ make helix/rev2/sc/back:KEY_MAP
  $ make helix/rev2/sc/under:KEY_MAP
  $ make helix/rev2/sc/oled:KEY_MAP
  $ make helix/rev2/sc/oledback:KEY_MAP
  $ make helix/rev2/sc/oledunder:KEY_MAP
  

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

[zvecr]

Changes a user keymap without sign off, if we can get @XScorpion2 to explicitly okay the change then we can move forward without going through that process.

[XScorpion2]

I give my approval

[zvecr]

@XScorpion2 Awesome! Cheers for that.

[mtei]

Thank you very much, @XScorpion2.

@zvecr, Thank you for explaining. I was aware of that, and if changing the 'xulkal' keymap was a problem, I was ready to undo it.

[XScorpion2]

Honestly, you could have just left my keymap broken too. I'm active enough and just so long as my code isn't deleted, I'll get around to fixing it soon enough.

[Curry]

@MakotoKurauchi with the addition of #7915, You need to add
#define DIODE_DIRECTION COL2ROW to the split-common config.h files, otherwise all keymap builds will fail.

[mtei]

This PR has been opened for two months but has not been merged yet. Please let me know if there is a reason not to merge.

[mtei]

This is something I created and approved by MakotoKurauchi, so of course I agree with Merge.

But is it OK to approve by me?

[drashna]

Ideally, it should have one more contributor approve it, but in this sort of case, it should be okay.