Simpler top-level cmakelists

[doingnz]

Description

Removed most of the custom RTOS & target logic as the approach encouraged additional script for each additional target.
This PR does not change the logic for the two ESP targets other than to use the same named CMake variables for the RTOS and Target folders to show how close it is to being the same as the other targets. Given the ESP targets are being reworked for the update to 4.x, I have left that change to the person doing the ESP update to remove ESP difference.

Motivation and Context

Ideally there would be no RTOS or TARGET specific logic in this top-level CMakeLists.txt to aim for reduced responsibility and remove chance of unexpected interactions when new platforms added. its purpose should be restricted to check a target exists and validate high level shared options common to all nanoFramework targets. It also manages the selection of the standard target or community target.

With this change, a new ${RTOS} & ${TARGET} will be found simply by creation of the folders under /targets. i.e. /targets/${RTOS}/${TARGET}

How Has This Been Tested?

Confirmed can build ESP32 and STM32 targets.

Screenshots

Types of changes

• Improvement (non-breaking change that improves a feature, code or algorithm)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Config and build (change in the configuration and build system, has no impact on code or features)
• Dependencies (update dependencies and changes associated, has no impact on code or features)
• Unit Tests (work on Unit Tests, has no impact on code or features)
• Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[nfbot]

Hi @doingnz,

I'm nanoFramework bot.
Thank you for your contribution!

A human will be reviewing it shortly. 😉

[josesimoes]

LGTM!

[nightlark]

@josesimoes I'm not sure how nfbot is deciding when to apply the invalid label, since it seems to be getting added to merged PRs and ones that have been closed and replaced by a newer PR. Given that hacktoberfest is apparently counting invalid labels towards disqualification, use of the label by nfbot should probably be paused until after October.

[josesimoes]

@josesimoes I'm not sure how nfbot is deciding when to apply the invalid label, since it seems to be getting added to merged PRs and ones that have been closed and replaced by a newer PR. Given that hacktoberfest is apparently counting invalid labels towards disqualification, use of the label by nfbot should probably be paused until after October.

@nightlark criteria for adding invalid label is for PRs that where closed without being merged. This one must have been a glitch resulting from the order the git events where processed. The code processing these hasn't been changed for months now. I've also randomly checked several other PRs and couldn't find any that was wrongly labeled.
Thanks for sharing your concern! 😃 👍🏻

Actually I've just found one. We'll look into this to understand why and fix it.