* STM32F7: Unconditionally enable QSPI workarounds

On the STM32769NI at least this patch is required for stable QSPI use.
Enable it uncondtionally in case other boards need it too.

Further discussions:

https://github.com/ARMmbed/mbed-os/issues/10049
https://github.com/ARMmbed/mbed-os/issues/15108

https://github.com/STMicroelectronics/STM32CubeF7/issues/52
https://github.com/STMicroelectronics/STM32CubeF7/issues/82

* QSPIF: Attempt 4-byte addressing on Macronix chips

mbed-os PR 11531 introduced 4-byte addressing in the QSPIF block device:

https://github.com/ARMmbed/mbed-os/pull/11531

During testing it was found that this code broke on the NRF52840_DK and
DISCO_F769NI.

The NRF52840_DK controller seems unable to handle 4-byte addressing at
all and has been disabled entirely in another code section.

The DISCO_F769NI breakage was attributed to the flash chip but after more
research I believe this is related to the QSPI controller, not the 4-byte
addressing itself.

Now that the QSPI controller has a workaround, enable 4-byte addressing
again and hope it works fine this time.

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.

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.

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.

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

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::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.

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.