Tweaks to how target.application-profile works

[multiplemonomials]

Summary of changes

Though I'm glad to have this setting in general, I realized that there are a few tweaks I'd like to make to how it works.

First of all, I thought about it some more, and I really don't think we need the 'auto' option. It's not actually needed in CI because we have the different JSON files we can point it to to select the profile, and I really think the code is simpler without it.

Second of all, I noticed that even when the application profile is full, mbed-baremetal still exists as a CMake target (and is exactly the same as mbed-os). I don't see a super good reason for this and I would rather it not exist in this situation. That way, if you try to do

if(TARGET mbed-baremetal)
    target_link_libraries(foo mbed-baremetal)
endif()

it will actually work as expected!

Impact of changes

• target.application-profile 'auto' option removed
• Only one of mbed-os and mbed-baremetal will exist in CMake, depending on the target.application-profile setting.

Migration actions required

Documentation

None (as the auto option was only really used internally, and the documentation states that the default is 'full').

---

Pull request type

[X] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[X] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

[ccli8]

yeah, it is clean without the auto option, then either mbed-os or mbed-baremetal is created exclusively