Make fvp work for anything other than aarch64 when being set as the test machine

[simpal01]

The current picolibc changes can't handle fvp being set as the test machine for anything other than aarch64. If fvp isn't set, it defaults to qemu, which works for now because the ARM fvp doesn't require anything special. However, when adding new aarch64 big-endian variants, one of the picolibc patches includes test-machine as an option in the Meson build scripts. Consequently, the library's CMake needs to set this option using -Dtest-machine=${TEST_EXECUTOR}. This means that for the armv8.1m library variant,we are explicitly passing the FPU, which can cause the error fvp: requested test machine not found since fvps are only defined for the aarch64 case.

[dcandler]

While this does solve the problem, it looks like it means an fvp version of the startup code will now be produced for everything, even though for non-AArch64 it's identical to the standard code. That duplication of work seems very inefficient: if the same code works for both test executors, it makes more sense to me to use it for both instead of generating two versions for the sake of satisfying an expected filename.

[simpal01]

While this does solve the problem, it looks like it means an fvp version of the startup code will now be produced for everything, even though for non-AArch64 it's identical to the standard code. That duplication of work seems very inefficient: if the same code works for both test executors, it makes more sense to me to use it for both instead of generating two versions for the sake of satisfying an expected filename.

At the moment we don't have a separate boot code changes for non-aarch64. But we will need separate QEMU/FVP startup code for A-profile AArch32, and probably R-profile AArch32 in the future. Building one bootcode object for M-profile could be an option, but building two objects would simplify things, and the bootcode objects are small so the compile time or distribution size is not going to be a big problem.