sensors: codegen for attr/chan/trig

[yperess]

Introduce phase 1 of the sensor code generation. In this phase, we flatten the sensor attribute/channel/trigger enums such that sensors which add their own private values will not collide with others. Downstream users can add their own sensor descriptors by modifying various cmake variables: ZEPHYR_EXTRA_SENSOR_YAML_FILES, ZEPHYR_EXTRA_SENSOR_INCLUDE_PATHS, and ZEPHYR_EXTRA_SENSOR_DEFINITION_FILES.

Note:

We're still working on adding the rest of the sensor.yaml files.

Why is CI failing?

CI doesn't allow new python dependencies to be added in the same PR that they're used. Instead we would need to first check in the python dependencies, then roll out a new version of the docker, then re-run this PR's CI.

Why not devicetree?

When we started off, devicetree was very heavily explored. 2 approaches were taken with devicetree.

1. Adding default values to bindings.
2. Adding child nodes to devicetree sensor nodes.

Details about devicetree limitations for sensors can be found at #71235. While this PR doesn't yet solve the exact issue in the issue, the additional metadata can/will be added once the basic descriptors are added.

Timeline

This is an MVP for the sensor.yaml which allows us feature parity with today + a small improvement where we're able to avoid custom attribute/channel/trigger collision. Along with the ability to statically assert that a sensor driver supports the features we need. The next steps are (keep in mind that some of these may happen in parallel):

1. Generate documentation. See sensor: codegen #81748 as an example. This documentation models after the board catalog and allows us to quickly search for sensor drivers matching some criteria.
2. Generate driver libraries. Looking at the adi sensors introduced by Analog Devices Inc we can see a great pattern emerging on how to abstract the bus, model the RTIO submit calls, and attribute handling. A lot of that information can be pulled from the sensor.yaml and we can generate a fairly comprehensive {compatible.part}.h and {compatible.part}.c which would handle the majority of the driver functions while leaving out a few stubs to be added by the developer. For example, this could look like (in cmake):

zephyr_sensor_driver(
  YAML
    sensor.yaml
  SRCS
    rtio.c
    decoder.c
    $<$<BOOL:${CONFIG_MY_SENSOR_I2C}>:i2c.c>
    $<$<BOOL:${CONFIG_MY_SENSOR_SPI}>:spi.c>
    $<$<BOOL:${CONFIG_MY_SENSOR_STREAMING}>:streaming.c>
)

3. Adding size information. Here we would introduce size information for both internal storage and decoded. This would allow us to go back to the second step and auto populate the buffers.
4. Add support to west manifests to be able to list additional sensor.yaml specs which would allow modules to append to the ZEPHYR_EXTRA_SENSOR_* cmake variables
5. Generate tests. Since sensors now explicitly say "I support reading channel X", we can generate tests for that. Assuming there's a fully implemented emulator, we should be able to verify that a driver actually implements what it says.

[nordicjm]

cmake indent is 2 spaces, apply comments throughout whole PR

[nordicjm]

why are there full stops in target names?

[yperess]

Why not? I've used them before in other projects. I'm happy to remove them. I use them to denote subpackage like targets. Makes it harder for things to collide when generating targets.

I'm happy to remove the . if you feel strongly about it.

[nordicjm]

why does every user need this?

[yperess]

The Pigweed python library is where we developed the sensor codegen library. This allowed us to start onboarding teams that don't use Zephyr to use the same sensor standard descriptor without having to add Zephyr as a dependency (yet).