RFC: use compatible name for prefix for device-specific API

[pabigot]

A number of devices including ams,ccs811 and maxim,ds3231 have capabilities that are not supported by generic subsystem APIs like sensor or counter. Access to these capabilities is provided by device-specific extensions like:

int ccs811_envdata_update(struct device *dev,
                          const struct sensor_value *temperature,
                          const struct sensor_value *humidity);
int maxim_ds3231_synchronize(struct device *dev,
			     struct sys_notify *notify);

Zephyr does not have a global documented policy on naming that takes into account future conflicts, e.g. by placing things in namespaces. This has recently caused several issues between external libraries and internal and public Zephyr code, and as Zephyr's in-tree capabilities expand the potential for conflict will only increase.

I propose that public API related to device-specific capabilities should use the device compatible for a prefix, e.g. ams_ccs811_ and maxim_ds3231_. This has several benefits:

• The longer name reduces the chance of conflict if two vendors produce devices with similar names;
• The vendor prefix will group the custom API in documentation indexes.

I don't propose that API for existing drivers like CCS811 be renamed (though I would support that), but only that new drivers like DS3231 (#17631) follow this practice.

[carlescufi]

I couldn't agree more @pabigot . Adding this to today's API meeting.

[carlescufi]

API meeting:
General consensus towards enforcing (and documenting) this. #24741 will include a patch to document this.