Namespace generated headers with zephyr/

[kr-t]

Problem description
Some of the generated headers have pretty generic names, i.e.: version.h, and can potentially conflict with other library / user applications. Ideally, all Zephyr's headers, in-tree or generated, should be namespaced with zephyr/.

Proposed change
To avoid potential conflicts with other library or user application headers due to generic names, introduce a zephyr/ namespace for all Zephyr-generated and in-tree headers. This can be achieved by modifying the CMake files and scripts responsible for generating these headers to include the zephyr/ prefix in their file names and updating the include paths in source files accordingly.

Additionally, ensure that the legacy include paths remains compatible during this transition and update the migration and release notes with details about this change and any necessary mitigation steps for users.

Please check: zephyrproject-rtos/zephyr#73114

Relevant migration notes: https://docs.zephyrproject.org/latest/releases/migration-guide-3.7.html#build-system

Real-time issue:
While trying to build modern zephyr (4.2) with wamr via --sysbuild (check this: https://docs.zephyrproject.org/latest/build/sysbuild/index.html) , following error is thrown:

wasm-micro-runtime/core/shared/platform/zephyr/platform_internal.h:10:10: fatal error: autoconf.h: No such file or directory
   10 | #include <autoconf.h>
      |          ^~~~~~~~~~~~
compilation terminated.

because it hasn't been generated yet.

This PR solves this issue and follows earlier migration guide.

[lum1n0us]

LGTM

[yamt]

is this (the use of __has_include) recommended by zephyr?

[kr-t]

I think Zephyr doesn't give advices to how-to support older platforms and generally advices to follow porting guides, which at 4.x versions just say do not have zephyr/ prefixes at all.

Since wamr includes below depend on the version, at this point we don't know whether we shall include generated files with or without zephyr/'s prefix. __has_include is a complier specific macro, and if we don't have it, we fallback to the zephyr/ prefixed generated files, which might work even with the never versions.

I'm fine with other methods determining which includes do we need, I just found this one as most appropriate one based on my experience. As another solution, we could just stop supporting older zephyr as a platform. We could also leave it as it is, but I feel that more and more projects would fail in the future if we don't follow Zephyr's changes.