Updated encoder config docs & standardization of existing shields

[petejohanson]

• Update new shield guide for new sensor/encoder settings.
• Add DTS section to encoder config docs.
• Update existing in-tree shields/boards to use the new encoder configuration consistently.

[caksoylar]

Can we also add a pointer to docs/features/encoders.md to the config page, for users that need to adjust the encoder properties in the keymap? Right now it says

See the New Keyboard Shield documentation for how to add or modify additional encoders to your shield.

but I feel like config page is better for adjusting already configured encoders.

[caksoylar]

This would close #1860.

[caksoylar]

Also a bit unrelated but since we are touching encoder definitions in all shields: Should we get rid of the recommendation to set CONFIG_EC11_TRIGGER_GLOBAL_THREAD=y by making it default? I don't know the nuances of when you wouldn't want that, but I don't think I have seen a config with it not used.

[lesshonor]

1. ...I was surprised to see a PR which was ostensibly for docs incorporate changes to shields and boards.
2. The suggested changes for MurphPad are at odds with my outstanding PR, which has been tested on an actual PCB and stock encoder provided by the vendor/creator. (I am also unsure if there is some reason its keymap was not modified—does the sensors node actually belong in the $shieldname.overlay file?)

[petejohanson]

1. ...I was surprised to see a PR which was ostensibly for docs incorporate changes to shields and boards.

Yeah, the PR title/summary got auto-populated by my first commit, and then I got to the follow up work. I will update accordingly.

2. The suggested changes for MurphPad are at odds with [my outstanding PR](https://github.com/zmkfirmware/zmk/pull/1786), which has been tested on an actual PCB and stock encoder provided by the vendor/creator. (I am also unsure if there is some reason its keymap was not modified—does the `sensors` node actually belong in the `$shieldname.overlay` file?)

So, we have a mix of approaches, probably in part because we weren't very diligent about how to structure things when encoder work got added.

IMHO, the "correct" way to do this is to add the sensors node in the overlay, and give it a label, e.g. sensors: sensors { so that it can be referred to in keymaps and updated as necessary.

So if you only installed encoders in certain positions, you might do:

&sensors {
  sensors = <&position_one_encoder>;
};

for instance. I didn't want to "rock the boat" too much as part of this refactor, but I'm certainly open to it if we want to be consistent so that future shields/boards that might copy others get it "right".

[petejohanson]

Also a bit unrelated but since we are touching encoder definitions in all shields: Should we get rid of the recommendation to set CONFIG_EC11_TRIGGER_GLOBAL_THREAD=y by making it default? I don't know the nuances of when you wouldn't want that, but I don't think I have seen a config with it not used.

I want to explore this for sure, not sure it's in scope for this or not, since really we need to get the docs/reference designs fixed ASAP to avoid future confusion.

I didn't create that as the default because the convention for generic sensor drivers is to not do so... What may make sense is to leave the driver Kconfig as is, but in ZMK's Kconfig override the default for our use. Thoughts?

[caksoylar]

LGTM, just noting the missing tweak for murphpad.

[caksoylar]

This one doesn't seem to have triggers-per-rotation defined (sensors node is in the keymap)

[joelspadin]

Looks good to me aside from the issue with murphpad missing triggers-per-rotation.