[BUG] make CONFIG_SOF_ZEPHYR_STRICT_HEADERS the default

[kv2019i]

Describe the bug/enhancement
When rtos include layer was added in #6161 , CONFIG_SOF_ZEPHYR_STRICT_HEADERS was added as a transitory tool.

This is still in place and can cause confusing issues as both XTOS and Zephyr headers are added to the include path by default.

To Reproduce
Build target, check .config

Reproduction Rate
100%

Expected behavior
OS include paths not mixed in build.

Impact
Slows down development of new features.

Environment
SOF main as of 2024-04-09

Work breakdown

Following subtasks identified (breakdown started in v2.11 cycle):

• xtos headers used to hook in memory layout definitions in platform layer, platform/lib/memory.h for SRAM_INBOX/OUTBOUT etl al
• xtos/sof/compiler_attributes.h -- zephyr/toolchain.h defines some but not all definitions SOF codebase needs, fork the definitions? rtos: branch compiler_attributes.h for XTOS and Zephyr #9489
• xtos/sof/compiler_info.h
• xtos/sof/init.h -- zephyr: add Zephyr version of sof/init.h #9592
• xtos/sof/trace/ -- no blockers, no use in Zephyr
• xtos/sof/trace/preproc.h -- used in SOF trace.h still -- Zephyr preproc.h implementation (OPTION B) #9603
• xtos/sof/list.h -- why in RTOS layer, this seems like a SOF specific SW API that is used very widely xtos: move list.h to application interface #9466
• xtos/sof/lib/agent.h -- not used in Zephyr builds, any need in the future? xtos: move sof/lib/agent.h to application interface #9490
• xtos/sof/lib/cpu.h -- no blockers, can be replaced with Zephyr
• xtos/sof/lib/dai.h -- no blockers, can be replaced rtos: add Zephyr implementation of sof/lib/dai.h #9457
• xtos/sof/lib/dma.h -- a complex case, lot of definitions still used plus lot of unncessary stuff for Zephyr builds rtos: branch out dma.h for Zephyr and XTOS #9560
• xtos/sof/lib/io.h -- no blockers, can be replaced
• xtos/sof/lib/mailbox.h -- complex case, dependencies to SRAM_INBOX/OUTPUT definitions in platform layer xtos: move sof/lib/mailbox.h to application interface #9562
• xtos/sof/lib/memory.h -- all definitions in platform layer, in intermedia, Zephyr version can use platform layer still rtos: add Zephyr implementation of sof/lib/memory.h #9552
• xtos/sof/lib/mm_heap.h -- medium complexity, mostly unused in Zephyr but some key definitions zephyr: sof/lib/mm_heap.h added Zephyr version #9467
• xtos/sof/lib/perf_cnt.h -- problematic, why is this in the RTOS layer, shouldn't this be agnostic SOF service? move back to app layer xtos: move sof/lib/perf_cnt.h to application interface #9494
• xtos/sof/lib/pm_runtime.h -- medium complexity, mostly unnecessary in Zephyr but some usage remains for Intel cAVS2.5 zephyr: decouple from platform pm_runtime.h interface #9495
• xtos/sof/lib/shim.h -- no blockers, can be replaced, directly uses platform layer platform/xtos: remove shim.h interface as it's no longer needed #9461
• xtos/rtos/alloc.h -- widely used interface in SOF, has audio extensions so no direct replacement in Zephyr
• xtos/rtos/atomic.h
• xtos/rtos/bit.h
• xtos/rtos/cache.h
• xtos/rtos/clk.h
• xtos/rtos/idc.h
• xtos/rtos/init.h
• xtos/rtos/interrupt.h
• xtos/rtos/kernel.h
• xtos/rtos/mutex.h zephyr: add rtos/mutex.h #9488
• xtos/rtos/panic.h
• xtos/rtos/sof.h
• xtos/rtos/spinlock.h
• xtos/rtos/string.h
• xtos/rtos/string_macro.h
• xtos/rtos/symbol.h
• xtos/rtos/task.h
• xtos/rtos/timer.h
• xtos/rtos/wait.h
• make CONFIG_SOF_ZEPHYR_STRICT_HEADERS=y at least for one SOF target
• CONFIG_SOF_ZEPHYR_STRICT_HEADERS=y for all SOF Zephyr targets

Screenshots or console output

[kv2019i]

Not sure I can tackle this in time for v2.10, but assigning for myself, as nobody else is assigned.

[kv2019i]

Update for v2.10: spent some time on this trying to make one Intel target build in strict headers mode, but could not complete the task. There is still quite a lot of use of e..g sof/lib/mailbox.h and sof/lib/memory.h in surprising places in audio code that needs to be cleaned up first. Also we have some SOF side functions list SOF list.h and perf_cnt -- for these, move to some common header might be easier. For now moving to v2.11 -- might be able to complete some of this work in June, but won't backport to 2.10 release (as no functional benefit for the release).

[kv2019i]

Work breakdown added to the issue description with already done worked marked as done.