[discussion] Decide whether or not to express FPU nuances for `@platforms//cpu:armv*-m*` constraints

We may want to avoid expressing FPU extensions in ARM Cortex-M CPU constraints.

# Proposal
Refrain from extending the set of `@platforms//cpu:armv*-mf` constraints, and annotate the existing constraint with a warning that it is kept around for compatibility reasons and shouldn't be carried forwards as a pattern.

# Why?

ARMv7e-M + FPU is relatively ambiguous:
Cortex-M4 (ARMv7e-M) optionally supports FPU instructions [via the FPv4-SP extension](https://developer.arm.com/documentation/ddi0439/b/Floating-Point-Unit/About-the-FPU)
Cortex-M7 (ARMv7e-M) optionally supports FPU instructions [via the FPv5-SP-D16-M or FPv5-DP-D16-M extensions](https://developer.arm.com/documentation/ddi0489/f/floating-point-unit/about-the-fpu)

These aren't the only optional extensions for Cortex-M processors either, so properly fully enumerating the extensions is a bit of a hassle when it comes to basic CPU constraints. It's a bit like having `@platforms//cpu:x86_64-AVX512`. It's likely best to leave these nuances to separate constraints that add dimensions rather than trying to enumerate every configuration across a single dimension. I don't necessarily think we should prescribe a solution for expressing architecture extensions, but I do think we should consider annotating the existing `@platforms//cpu:armv7e-mf` with a warning that it shouldn't be replicated but will be retained for backwards compatibility.

Start by reviewing the existing @platforms//cpu:armv*-m* constraints, especially @platforms//cpu:armv7e-mf, and the linked ARM FPU references. The discussion needs a settled decision on whether FPU nuances belong in these constraints and what compatibility warning or extension-constraint policy should be documented.

Written by the indexing model from the issue text.