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?