Improve tiered support system and compilation flags introduction.

[lum1n0us]

• Review the compilation flags with the latest code once more.
• Indicate that all features should be used with caution.
• Ensure each compilation flag has its own introduction.
• Correct all links.

[lum1n0us]

I can barely recall 😞 all the targets we have tested. I need help verifying them.

[lum1n0us]

If everyone agrees with the tiered-support system, should we apply it throughout the entire project? For example:

• Labeling issues with a tiered support level so that people can have proper expectations regarding their questions. There is already an issue to track this.
• Shaping CI to match the tiered-support system. For instance, Per-PR CI will only cover all tier A features, targets, and platforms, while Nightly CI will cover all tier B features, targets, and platforms.
• Shaping released binaries to match the tiered-support system. For example, only tier A features and targets/platforms will be released in the iwasm binary.
• Probably more... please feel free to add.

[woodsmc]

Just wondering, why Ubuntu and not Linux? - I know many users are using WAMR with Debian and with Yocto.

Would we need specific Linux tests for those platforms?

[woodsmc]

If everyone agrees with the tiered-support system, should we apply it throughout the entire project? For example:

• Labeling issues with a tiered support level so that people can have proper expectations regarding their questions. There is already an issue to track this.

This is a great idea.

• Shaping CI to match the tiered-support system. For instance, Per-PR CI will only cover all tier A features, targets, and platforms, while Nightly CI will cover all tier B features, targets, and platforms.

Umm, so a contribution could look like it will pass, but then fail in the nightly build? Ty at would be confusing and a little frustrating, wouldn't it?

I don't think we'd want to get to the point where some contributions work in tier A, but fail in tier B. Or have code contributions which actively make tier B worse.

I'd say, that the tier reflects speed of bug fix / support. But we'd not want to make tier B worse, right? - otherwise we could get to a point where the we'd struggle to make a release for tier B.

So, maybe we need to keep the CI/CD the way it is? - build for all?

What do you think?

• Shaping released binaries to match the tiered-support system. For example, only tier A features and targets/platforms will be released in the iwasm binary.

• Probably more... please feel free to add.

[lum1n0us]

It would be beneficial to have a CI environment for Debian and Yocto, similar to the Windows platform. The slow progress is likely due to the need for experienced maintainers to create and maintain these environments.

[lum1n0us]

We definitely don't want to make tier B worse. I am fully supportive of covering both tier A and tier B in per-PR CI and releases.

Therefore, we should define and add more tests and platforms according to the tier support, such as CI for Zephyr, ESP-IDF, MIPS (?), and tests for WASI-NN, etc.

Btw, does this mean we all agree that we can lower the priority of tier C in CI and releases, such as releases for Windows and CI for Android?

[TianlongLiang]

LGTM with a minor comment