Rename inconsistently named testing-related variables. Also fix STM32CUBE not working from application code.

Convert storage/ targets into STATIC libraries

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

QSPIF: Add missing mbed namespace prefix to header file

CMake: QSPIFBlockDevice: Guard unit test directory ...

In the QSPIFBlockDevice component we checked if BUILD_TESTING was
enabled before adding the QSPIFBlockDevice/UNITTESTS subdirectory. In
the parent blockdevice/CMakeLists.txt we added the QSPIFBlockDevice
subdirectory to the build under two separate conditions:

* when "QSPIF" is present in MBED_TARGET_LABELS
* when building only unit tests

This wasn't quite enough, as when we build greentea tests for some
targets QSPIF is enabled in MBED_TARGET_LABELS, causing the
QSPIFBlockDevice subdirectory and its unit tests to be added when
building greentea tests. This caused a test failure on targets which
enable QSPIF:

```
The following tests FAILED:
	 40 - qspif-unittest_NOT_BUILT (Not Run)
```

To fix this we need to specifically check that we're not building
greentea tests before adding the QSPIFBlockDevice/UNITTESTS directory to
the project.

Part of this issue is our reliance on MBED_TARGET_LABELS to pull
features in to the build. We should refactor our usage of
MBED_TARGET_LABELS and use CMake target dependencies where possible.
Then we wouldn't need to add subdirectories under various, often
conflicting, scenarios. Instead the targets would always be available
and we would just choose which ones to actually build in different cases
using CMake target linking.

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.

QSPIFBlockDevice: Add quirk to ignore overlaying sectors on S25FS512S ...

The entire flash chip S25FS512S consists of uniform 256KB sectors.
Additionally, it has three configurations:
* 0x01: Eight 4KB sectors (32KB in total) overlaying the start of
the first 256KB sector
* 0x03: Eight 4KB sectors (32KB in total) overlaying the end of the
last 256KB sector
* 0x05: No overlaying sectors

The active configuration is determined from bit fields of two
registers, CR1NV and CR3NV.

Mbed OS does not currently support partially overlaying sectors,
meaning that with eight 4KB sectors overlay a 256KB sectors, the
remaining 224KB (== 256KB - 8 * 4KB) of the big sector can't be
correctly handled. Supporting such scenario would involve a large
amount of rewriting in Mbed OS's BlockDevice, SFDP and their tests,
and may increase the code size.

So, this commit applies a quirk to always report configuration 0x05
(no overlaying sectors). Even if 0x01 or 0x03 is the real configuration,
they are compatible with the 0x05 configuration because 256KB sectors
exist in all cases.

Note: This quirk does *not* change actual configurations on hardware,
because registers CR1NV and CR3NV are one-time configurable (OTP) -
each bit field has a factory value of 0 and can be changed to 1 by the
user but not back to 0. So QSPIFBlockDevice avoids changing them.

QSPIFBlockDevice: Add quirk for inconsistent CR3NV register value ...

Cypress S25FS512S's SFDP table suggests that bit-1 of the register
CR3NV on 25FS512S should equal 1. But it is a known issue that the
value is actually 0 on hardware. So if we query the value of CR3NV
during configuration detection, we can't find a configuration that
matches the SFDP data. This issue has been discussed in the Linux MTD
(Memory Technology Devices) mailing list:
https://linux-mtd.infradead.narkive.com/ylHK6CyT/spi-nor-fs512s-incorrect-cr3nv-1-value

This commit adds a quirk to report bit-1 of CR3NV as 1.

Note: In Mbed OS, vendor-specific quirks can only be handled in block
devices. The SFDP functions assume data from hardware to be correct.
So this quirk is in the block device.

QSPIFBlockDevice: Use fully-qualified include path ...

In Mbed OS, each library has an `include/<library>/` subdirectory
containing headers. The recommended way to include a header is
`#include "<library>/<header>.h"` to avoid potential conflicts with
any external modules that have same names of headers.

This is not enforced yet, and both include/ and include/<component>/
are in a library's include paths, to avoid breaking preexisting
Mbed projects that don't follow the recommendation. But code within
Mbed OS should follow it at least.

SFDP: Add more parameters to the reader callback ...

The SFDP functions parse SFDP data which is fetched by a callback
called `sfdp_reader` provided by {SPIF,QSPIF,OSPIF}BlockDevice.
Currently, this callback interface only takes a read address and an RX
buffer to store output data. This has been enough, because other SPI
parameters are always the same when fetching the SFDP table only -
they are just hardcoded in each reader.

But in the future we will add support for flash devices with multiple
configurations (in a subsequent commit), and to detect which
configuration is enabled, we will need to send detection commands
which require device-dependent SPI parameters:
* address size
* instruction
* dummy cycles

This commit
* turns the above SPI parameters from predefined/hardcoded values
into parameters of the callback
* lets the SFDP functions pass the above parameters to the callback
(Note: To read the SFDP table itself, those values are constants
defined by the standard, not tied to any particular device, so they
can be known to the SFDP functions)
* updates the callbacks implemented by {SPIF,QSPIF,OSPIF}BlockDevice
* updates the mock callback for unit tests and expectations

BlockDevices: specify mbed namespace where needed

Update include paths to SFDP.h

Merge pull request #13960 from harmut01/2260_erase_size_const ...

Add const keyword to get_erase_size declaration

Fix integer type warnings in SFDP and *SPIFBlockDevice

Add const keyword to get_erase_size declaration ...

Add const to function declaration. Const objects cannot access const
safe functions, a compiler error is thrown if one tries to do so. This
helps ensure that the object calling the method will not be modified.
This is espescially desirable in functions where all we need to do is
query existing data and not make any alterations.

[Q/O/]SPIFBlockDevice: remove logic for unaligned erase, as alignment is checked ...

[Q/O/SPIFBlockDevice::erase() begin with an alignment check,
after which unaligned erases should not happen or be allowed.

If the erase address is not aligned to the value returned by
sfdp_iterate_next_largest_erase_type(), it indicates an
internal error in erase table parsing which should not be
hidden.

QSPIFBlockDevice: fix misconception in minimum program size ...

Prior to this PR, the minimum program size (QSPI_MIN_PROG_SIZE) of
QSPIFBlockDevice was 256 by default and 512 for some targets.
Those values were in fact page sizes, not program sizes.

Here's an explanation:
* Most QSPI flashes can be programmed to a granularity of a
  single byte or a few bytes - no need to be a whole page.
  This should be the value of QSPI_MIN_PROG_SIZE. Applications
  need to align buffer sizes to this granularity when
  programming QSPI flashes.
* Each sending of the underlying QSPI program signal requires
  destination bytes to be located within the same page.
  If a QSPIFBlockDevice::program() call crosses page boundaries,
  this function breaks down the operation into multiple chunks,
  so it's not a concern for the application.

So this PR changes the default program size to 1 (byte), and
for targets with a 4-byte (1-word) read size it overrides the
program size.

Note: No config is needed for the page size, as it comes from
the SFDP table parsed during initialisation.

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: Fix blockdevice components source and include paths ...

This file paths were updated on master and this was broken after
rebasing.

CMake: Fix failures due to device_key and storage dirs move

CMake: Add support for storage dir

QSPIF: options to preset reset sequence for legacy SFDP ...

The first revision (1.0) of SFDP (ref: JESD216) does not include
fields for software reset support. It's only been added in the
second revision (1.5) (ref: JESD216A).

Some Mbed OS targets such as DISCO_F746NG include flashes with
legacy SFDP, thus we add an option to preset the reset mode.

Rename to more readable include header directory component name

Refactor storage COMPONENT_xx directory

Update the header file reference

Storage directory restructure: ...

- Move mbed-os/features/storage to mbed-os/storage
- Move components/storage/blockdevice to storage/blockdevice/COMPONENT_xxx