CMake and bazel disagree about PICO_DEFAULT_XXX_IMPL

[kilograham]

For example PICO_DEFAULT_FLOAT_IMPL in the SDK would be pico_float_vfp whereas it would be vfp in the bazel build.

I noticed this when trying to add PICO_CMAKE_CONFIG for them, as it breaks the bazel checks.

I guess this happened because bazel enumerates the possibilities, whereas arguable the CMake version allows you to replace it with any library of your choice. However the CMake version is confusing since you call pico_set_float_implementation(TARGET vfp).

So, what to do?

1. Loosen the bazel build var checks (and keep the behavior the same)
2. I think it is probably unlikely that people have set PICO_DEFAULT_XXX_IMPL to anything other than pico_xxx_foo values, though they may have done that. So maybe we change the CMake behavior to be PICO_DEFAULT_FLOAT_IMPL=vfp but strip pico_float_ off the front if present

I'm certainly leaning to wards 2, but doing so inline in pico_float/CMakeLists.txt is probably incorrect as the user may have set it later in their own (in fact on looking at the code, all but PICO_DEFAULT_DOUBLE_IMPL are set inline explicitly without a definition check, so if people are overriding they must be doing so later).

I think however this is probably a little used feature - i didnt obviously see any uses of DOUBLE, or PRINTF on github... therefore i think we just do the stripping (it is probably possible in post 3.24 with PATH:IS_PREFIX generator expressions but i don't think it is worth it)

[kilograham]

cc @armandomontanez

[kilograham]

I think however this is probably a little used feature

Not least since they aren't in the documentation (much)!