Make the documentation more specific to dongles.
Moves some of the configuration around.
Adds an option for building firmware with left as central.
Clarifies different MCU usages.
Normalizes file names.
Removes duplicate warning.
* Studio will use stable layer IDs to refer to layers, so that
layer reordering doesn't affect behavior bindings, so update to match.
* Fix a few layer metadata entries that missed being refactored.
* Because settings load is delayed now, enable external
power on init, and let it be disabled on settings load
later, to ensure power is on early for
other peripheral initialization.
Fixes: #2361
* Add bindings to allow creating multiple physical layouts that specify
their key's physical attributes, and the matching matrix transform
and dependant kscan to use.
* Synthesize a basic physical layout if none specified, for backwards
compatibility.
* Update matrix transform API to explicitly pass in the selected transform
to the API instead of using a fixed chosen transform.
* Move kscan subscription and handling into the physical layout code, so
that selecting a different physical layout at runtime can also use the
correct kscan instance.
* Add `physical_layouts.dtsi` file to include so you can use the
pre-configured `&key_physical_attrs` for adding you layout keys.
* Avoid doing duplicate calls to setings_load_subtree, which iterates
NVS fully each time under the hood, and instead use on settings_load
later in the lifecycle.
* Add a new feature for tracking a given behavior by a new concept
of a "behavior local ID" which is a stable 16-bit identifier for
a given behavior, that is resilient to new behaviors being added
and requires no additional work on the part of the behavior
authors.
* Add implementations for either settings lookup table, or CRC16
hashing of behavior device names for generating behavior local
IDs.
This adds a new config value `ZMK_HID_SEPARATE_MOD_RELEASE_REPORT`
where, if enabled, the report for a key release is sent separately to
the accompanying modifier release signals, which are then sent in a
second report.
This fixes an issue where certain applications are unable to work with
implicitly modified keys (e.g. colon) due to them registering the
modifier release prior to the actual key release.
Have tested this on my personal keyboard and `wev` now shows the signals
in the correct order.
=> **Previously:** ```LSHIFT (pressed) -> colon (pressed) -> LSHIFT
(released) -> **semi**colon (released)```
=> **Now:** ```LSHIFT (pressed) -> colon (pressed) -> colon (released)
-> LSHIFT (released)```
(This time without accidental files)
