Clean up top-level build file and build options, fix build issues on MinGW

QSPIFBlockDevice: Add unit test for the S25FS512S quirk ...

Add a test case to verify that the quirk on `CR1NV` and `CR3NV`
registers get applied by `QSPIFBlockDevice` when the flash device
is S25FS512S.

`QSPIFBlockDevice` depends on the SFDP functions and the `QSPI` class,
but we can't use gMock on them because:
* SFDP functions are global functions, whereas gMock only supports
mocking class member functions.
* A mocked class is injected into the test subject, but passing a
preexisting `QSPI` instance into `QSPIFBlockDevice` is not possible
(unless we resort to pointers). For details, see comments in
test_QSPIFBlockDevice.cpp.

So fakes of the `QSPI` class and any SFDP functions involved are
defined in test_QSPIFBlockDevice.cpp.

CMake: Add option to enable greentea tests ...

Add an option to enable the greentea tests independently from the unit
tests.

We can't just use the typical BUILD_TESTING option to enable greentea
tests. BUILD_TESTING enables unit tests and fetches googletest, which
are compiled for the host. Greentea tests are cross compiled and require
a toolchain file. For this reason we add a new option just to enable
greentea tests, preventing build failures triggered by the unit tests
and googletest.

CMake: Only build unit tests if Mbed OS is the current project ...

Typically when adding a unit test directory to a CMake project a check
will be used to ensure the subdirectory is added only if the following
are true:

* The BUILD_TESTING option is set to ON.
* The current CMake project is the top-level project.

The reason being, if a downstream project includes our project they
generally don't want to build our unit tests.

In mbed-os, we do correctly specify the above condition before adding
the central UNITTEST subdirectory, which fetches googletest and adds the
"stub" libraries the unit tests depend on. However, we only check if
CMAKE_CROSSCOMPILING is OFF (or undefined) before actually adding the
unit tests. This mismatched logic would lead to unexpected build
failures in various scenarios. One likely case could be: a downstream
project including mbed-os happens to set CMAKE_CROSSCOMPILING to
OFF/undefined for any reason (possibly to build its own unit tests).
mbed-os would go ahead and attempt to build its tests without fetching
googletest or adding the required stub targets.

To fix the issue replace the check for CMAKE_CROSSCOMPILING in the unit
tests with the same BUILD_TESTING idiom we use for adding the central
UNITTESTS subdirectory.

CMake: Add add_subdirectory of unittests ...

- add every libraries unittest directory into respective CMake
  which allows to include unittest source into build based on
  MBED_BUILD_UNITTESTS flag

CMake: Add support for OSPIF blockdevice

Move SFDP into blockdevice where it belongs to

CMake: Rename CMake targets ...

* mbed-os renamed mbed-core
* mbed-os-<COMPONENT> renamed mbed-<COMPONENT>

CMake: Componentize Mbed OS into multiple CMake targets (#13732) ...

Aside from the core mbed-os CMake target, a number of targets have been created so they can optionally be included by application executables that require them using `target_link_libraries()`.

Co-authored-by: Martin Kojtal <martin.kojtal@arm.com>
Co-authored-by: Rajkumar Kanagaraj <rajkumar.kanagaraj@arm.com>

CMake: Add support for storage dir