Because global behaviors have to exist on both the central and split
regardless if the user references them in their keymap, we can't omit
the behavior declaration if the user doen't reference it and decide to
compile it later based on the existence of the behavior declaration. The
best option seems to be to decide whether to compile those behaviors
based on the feature Kconfig flag. This also means that the two reset
behaviors will always be compiled into both sides.
Removed the label property from built-in behaviors, custom behaviors
defined in a few keymaps, and macros generated with ZMK_MACRO().
Now that node names are used to identify behaviors, and names only need
to be unique within the set of behaviors, the names of all behaviors
have been shortened to be similar to their original labels.
This means that any keymaps which reference behavior nodes by name
instead of by label will need to be updated. Keymaps typically use the
labels though, so most keymaps should be unaffected by this change.
* GATT characteristic allowing passng data + behavior
label to invoke the behavior on the peripheral side.
* Behaviors have a locality setting to specify where they run.
* Build reset/power/RGB on peripheral.
* Use lesser-known DT features to skip behaviors not referenced
in the user keymap
* Update the behaviors to skip code if no nodes found.
* Remove some empty config/data structs where unused in
behaviors.
