Remove uses_fp parameter from RTAPI and HAL APIs

[grandixximo]

Complete removal of the uses_fp parameter for 2.10. All threads now unconditionally save and restore FPU/SSE state.

RTAPI: remove uses_fp from rtapi_task_new(), remove RTAPI_NO_FP and RTAPI_USES_FP constants, hardcode FPU save in rt_task_init_cpuid.

HAL: remove uses_fp from hal_export_funct(), hal_export_functf(), hal_create_thread(). Remove uses_fp field from hal_funct_t and hal_thread_t structs. Remove addf FP compatibility check. Remove FP column from halcmd and halrmt display.

Components: remove uses_fp argument from all hal_export_funct and hal_export_functf call sites. Remove base_thread_fp from motion module, fp1/fp2/fp3 from threads component.

halcompile: remove OptFP grammar rule, fp/nofp parsing, and fp-related code generation and documentation output. Remove fp/nofp from all in-tree .comp files, conv.comp.in and mkconv.sh.

Documentation: remove uses_fp from API man pages, remove FP thread references from tutorials and guides.

Out-of-tree components must be updated to the new API signatures.

Ref: #3895

[grandixximo]

Hopefully I did not miss any...

[BsAtHome]

You should not remove the OptFP rule in halcompile just yet. Instead you should add the warning from my patch (and always return 1). That would give people an indication what is actually happening and gives them time to fix their code. The next release beyond 2.10 we can remove the rule completely.

It is not clear whether it is appropriate to change the HAL API in 2.10. It feels as too much too crude too soon. It is more appropriate to warn users appropriately that nofp no longer works, is deprecated and will be removed in the future. We need give people some grace period to fix their stuff, just like in halcompile.

[grandixximo]

what about #3286
If that is planned for 2.10 might as well no?

[andypugh]

what about #3286 If that is planned for 2.10 might as well no?

I am not sure it still is, but even if it is, I think that the discussion has made it clear that the API for out-of-tree components shouldn't change.

[grandixximo]

I'm not so sure the discussion points in that direction anymore.
If anything it is clear, the API for out-of-tree components will change, when is the question.
If noparam is to be merged, that breaks stuff already, we are breaking a bit this version, and bit more the next? I think @rmu75 is on the rip the band aid now team, got a couple of integrators on Discord with out of tree components, they don't seem to mind 2.10 breaking their comps, as long as we make the transition painless, a .comp and .c component helper when building ala updat_ini, and clear warning that the comps are incompatible and need rebuilding if they try to run old components.

I think is a reasonable goal, but we are moving it to next release?

[andypugh]

I am not sure that "noparam" will actually break the API, as the only way to set parameters that I am aware of is the "setp" hal command, and that works equally well when parameters become pins.

We have been steadily changing parameters to pins for many years now, and don't seem to have been breaking things.