* 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.
Before this change, if a matrix position was not present in the transform,
various incorrect behaviors would happen:
1) In some cases out-of-bounds accesses:
Note that the size of the`transform[]` array does not necessarily match
the size of the matrix. So for example if key position
(ZMK_MATRIX_COLS-1, ZMK_MATRIX_ROWS-1) is not present in the transform,
but ends up being pressed, then the array will be accessed beyond its
size, and any data could be returned.
2) In other cases the 0th position in the keymap will be used because
the `transform[]` array is initialized to all zeros.
