Provide consistent deprecated behavior and reduce downstream breakage

[keith-zephyr]

Need consistent behavior for deprecated objects
The behavior of builds varies based on the type object that is deprecated and also varies based on the toolchain used.

For example, adding a label property to the qemu_x86.dts file results in a warning when running west:

$ west build -b qemu_x86 samples/hello_world
...
'label' is marked as deprecated in 'properties:' in /workdir/zephyr/dts/bindings/mtd/zephyr,emu-eeprom.yaml for node /eeprom1.
...
[138/138] Linking C executable zephyr/zephyr.elf

But running the same thing under twister, results in a build failure, because warnings are promoted to errors:

./scripts/twister -T samples/hello_world/ -p qemu_x86 -v -i --clobber
...
devicetree error: 'label' is marked as deprecated in 'properties:' in /workdir/zephyr/dts/bindings/mtd/zephyr,emu-eeprom.yaml for node /eeprom1.
...
-- Configuring incomplete, errors occurred!

This also demonstrates how deprecation can break downstream users. Any downstream projects that promote warnings to errors see their downstream builds fail. This forces downstream repos to immediately fix deprecation errors, or disable the warnings-as-errors flags.

Proposal
If this can be supported by the tooling, it would helpful if deprecated objects only generated an informational message during the first TBD months. At some later point, the deprecated message would be switched to the current behavior to generate a warning. And then as a final step, the deprecated object is removed completely.

[keith-zephyr]

@carlescufi At the last process meeting you also mentioned that not all deprecated objects are treated the same (e.g. Kconfig, vs API, vs devicetree). Can add a comment with the inconsistencies you are aware of?

[carlescufi]

There are at least 4 types of deprecation that I know of:

• Compiler: whenever __deprecated is used in source files
• Kconfig: whenever CONFIG_DEPRECATED is selected, then the kconfig script issues a deprecation warning (see Support deprecation of Kconfig symbols #47835)
• Devicetree: The devicetree scripts can issue a deprecation warning
• CMake: Some older Kconfig options, or even CMake functions, use the CMake warning functionality to warn of deprecations

[tejlmand]

• CMake: Some older Kconfig options, or even CMake functions, use the CMake warning functionality to warn of deprecations

Ideally we should always be using message(DEPRECATION <msg>) in CMake and not warning, cause DEPRECATION offers some nice features:

• CMAKE_ERROR_DEPRECATED
• CMAKE_WARN_DEPRECATED