[cpullvm] Add armv7m -mfpu=fpv5-d16 hard float variant

[jonathonpenix]

The intention here is to offer a variant for Cortex M7 users with fpv5-d16 enabled.

There's a few misc. things to note here:

• The normalized triple clang uses when -mcpu=cortex-m7 is used is actually along the lines of thumbv7em* rather than the thumb7m we use here. Our multilib.yaml.in has mappings for these which we inherited from ATfE. So, align with what their configs seem to do and stick with thumbv7m.
• Picolibc is the only libc we want to support for this variant--a musl-embedded variant is intentionally omitted as we're moving away from musl-embedded.
• This variant is built without PIC support. The relevant user isn't using PIC and we've had issues with PIC + eld + Zephyr in the past for 32bit Arm targets (see [cpullvm] Add additional variants for testing Zephyr #309) so let's default towards nopic.
• We build our other armv7m configurations with -mno-unaligned-access (and we don't have both aligned and unaligned variants like ATfE). But, the relevant user build here is resolving to -munaligned-access so I'm not going to force -mno-unaligned-access in the library build unless we have a particular need.

[pzhengqc]

Can we add a test case for this?

[jonathonpenix]

Whoops, yes, a test is definitely needed. Thanks for catching that!

Looking at it now, looks like some other variants slipped through the cracks too--will add stuff for those separately.

[pzhengqc]

LGTM, thanks!

[zhaoshiz]

the relevant user build here is resolving to -munaligned-access

We should be Ok if the targeted hardware supports unaligned-access. Otherwise we may need to comeback and force alinged access.

[jonathonpenix]

Yeah, this is a fairly consistent thing in most of our library variants (we don't force align it, but also don't strictly require a specific alignment flag/setting for multilib). As far as our picolibc variants go, I think our armv7m variants are the notable exceptions here (where we do force the alignment when building).

I don't remember why this happened offhand (in our musl variants we usually force align things consistently, but downstream I don't think we were that consistent about it--ex: musl-embedded would be force-aligned but nothing else).

I guess three ideas that seem reasonable to me (which aren't all mutually exclusive):

1. Start matching -munaligned-access (or equivalent) in our multilibs and leave our build flags as-is. This way we at least have some compile-time safeguards in place.
2. Leave our multilib matching as-is, but more consistently force alignment (set -mno-unaligned-access or equivalent) in the build flags. I think this should be safer that what we have today? Not sure if there are other impacts (code size, performance, etc.).
3. Provide both aligned and unaligned configs similar to Arm

I'm not sure if we want to do 3 yet, but 1 at least would be a relatively quick/un-invasive change that might give us better safeguards. 2 seems ok too, but again I'm not sure what other impacts it might have.

@zhaoshiz do you have thoughts on any of these?

[apazos]

Discussed with Jonathon and we decided to go with (1) in mainline and branch.

[jonathonpenix]

Pushed the change to enforce -munaligned-access. FWIW, I think most of our other Arm/AArch64 variants have similar quirks/pathologies here.

Will push a separate PR to discuss what should be done with those--trying to keep this PR small-ish/suitable for going into the 22.x branch.