cpu/cortexm-fpu: use it via a feature instead of DEFAULT_MODULE

[aabadie]

Contribution description

This PR reworks how cortexm_fpu is managed: it applies the suggestion from @haukepetersen in #6630 (comment).

This allows to remove reference to DEFAULT_MODULE from a file that is included from a Makefile.include and not from a Makefile.dep but also to finely filter when the feature should be used or not.

To achieve this, I have to know which CPU_ARCH is used early (in Makefile.features): so the first commit of this PR is moving all CPU_ARCH/MODEL defined in Makefile.include to Makefile.features. I can provide this commit in a separate PR if requested by reviewers.
The other commits are just introducing and using the usual management of feature, and applying it to the new cortexm_fpu feature.

Testing procedure

• A green Murdock
• The following commands should work, with and without the patch below:

make BOARD=nucleo-l476rg -C tests/thread_float flash term
make BOARD=nucleo-f722ze -C tests/thread_float flash term
make BOARD=nucleo-l073rz -C tests/thread_float flash term

patch:

diff --git a/tests/thread_float/Makefile b/tests/thread_float/Makefile
index 59810e199fa..bc3015cd4c0 100644
--- a/tests/thread_float/Makefile
+++ b/tests/thread_float/Makefile
@@ -4,6 +4,6 @@ USEMODULE += printf_float
 USEMODULE += xtimer
 
 # Use CortexM FPU when available (only on M4F and M7 CPUs)
-FEATURES_OPTIONAL += cortexm_fpu
+# FEATURES_OPTIONAL += cortexm_fpu
 
 include $(RIOTBASE)/Makefile.include

Issues/PRs references

This PR is based on #13174 to be able to know the value of CPU_ARCH early and be able to determine if the cortexm_fpu feature is provided.

[aabadie]

@fjmolinas, if you have some time today, this PR is ready for review (since #13174 was merged!)

[benpicco]

So the FPU only gets used in this test (or when explicitly requested), otherwise software emulation is used.
What is the benefit of that?

If you have an FPU that should always be preffered over float-abi=soft, no?

[aabadie]

Good point, I'll update the PR in that direction !

[aabadie]

I've been trying and I realized that to be possible it would need #9913 to be fixed first.
This is because cortexm.inc.mk is included before processing the dependency resolution and this PR relies on this mechanism. Even if we would keep the FPU by default (using a default module), that would still be required (this is what I was thinking of and tried actually).

If you have an FPU that should always be preffered over float-abi=soft, no?

Yes probably.

I think I'll rework that PR and cut the CPU_ARCH/FAM move out of it.

[fjmolinas]

@aabadie can you give me an update on the status here?

[aabadie]

closing in favor of #13738