Add double-precision FP math library, and support in stmhal for it

[dpgeorge]

This PR has the following:

• addition of new lib/libm_dbl/ dir with math routines for double-precision floating point; this is taken directly from musl 1.1.16
• modify stmhal/Makefile to support (via a config option) building with this instead of existing single precision math library (pyboard has been verified to work with this library, using software double prec); single precision remains the default and is still used for all F4/L4 boards
• update relevant F7 boards to use double precision
• update stmhal/Makefile to use hardware double precision instructions on those F7 MCUs that support it

This PR should be good to merge. The only real question is how to name/structure the addition of the new libm code. It could go in:

• libm with single prec code (gets a bit messy): lib/libm/
• a subdir within libm (but then single prec code should be moved to match it): lib/libm/dbl/
• a new dir within libm (this is what I chose): lib/libm_dbl

Comments/suggestions/etc welcome.

[pfalcon]

libm with single prec code (gets a bit messy): lib/libm/

How e.g. newlib or musl keep that? I'm sure they keep everything in one dir, in "f" vs "d" files, or worst-case, even in the same file. Then the only concern of "messy" would be that upy's libm/ is collected from different sources. Then having lib/libm_dbl is indeed a good compromise.

[dpgeorge]

How e.g. newlib or musl keep that? I'm sure they keep everything in one dir, in "f" vs "d" files

musl keeps everything in the same directory (mostly, it has arch specific optimisations in subdirs of libm), and the filename (based on the C function name) is enough to distinguish between the single and double (and long double) variants.

Then the only concern of "messy" would be that upy's libm/ is collected from different sources.

Yes, for single precision there are some files from musl, some from newlib, and some minor ones written by me. But, the filenames are still unique and everything could be put together in libm.

The main reason to separate was simply so one would know which set of files to use for single prec and which set to use for double prec.

I'm really not fussed where the files go.

[dpgeorge]

Ok, this was merged with the double precision FP libary in lib/libm_dbl. In the end the main reason to keep it in a separate directory (separate to lib/libm) is that it's easier to keep track of the upstream source and licensing of these files (the new files in libm_dbl all come from musl 1.1.16 [except a few I wrote by hand, which are listed in the README] but those files in libm come from an older version of musl plus some from newlib).