hwmv2: cmake: Use only one defconfig

[57300]

Commit 84a7f75 enabled sourcing several defconfig files for a single board, ordered from least to most specific to the selected board variant. The assumption was: given two targets of the form <board>/<soc> and <board>/<soc>/<variant>, the latter would naturally inherit configuration from the former.

However, having multiple defconfigs doesn't make sense, and in practice, they tend to clash with each other, which complicates porting.

Another motivation for doing that was to make <board>_<soc>_defconfig optional, so that <board>_defconfig could be used instead, if present. This can still be achieved by constraining the _defconfig lookup to only use the most specific file available, just like .dts lookup.

Relevant changes to zephyr_file() have been reverted.

This means that <board>_<revision>.conf overlays, which were meant to be deprecated, are no longer replaced by revision-specific defconfigs, so they need to be un-deprecated. None of the currently ported (merged) boards are affected by this change.

[tejlmand]

you can always create sample overlays that clash with board defconfigs.

or you can put it another way, a board defconfig should not prevent a sample from disabling a feature if that feature is not crucial to the board.

If looking at this specific case, the boards/qemu/qemu_cortex_a53/Kconfig.defconfig could instead be used to set a different default int value, like:

config QEMU_ICOUNT_SHIFT
        default 4
        depends on QEMU_ICOUNT

No reason to do this in _defconfig if it break inheritance or samples ability to adjust a value.
In fact, this pattern is exactly what is used by other Kconfig.defconfigs, such as: qemu_cortex_a9 and qemu_x86.

[57300]

config QEMU_ICOUNT_SHIFT
        default 4
        depends on QEMU_ICOUNT

That works, although it would be nice if the migration script could make these kind of adjustments as well.
Applied in #68805 for now.