Add three21kins analytical kinematics solver

[sleepybishop]

Hello! This PR ports the three21kins kinematics solver from gomotion into LinuxCNC

There is a need for a simpler and more flexible kinematics solver in LinuxCNC for robot arms:

• The existing genserkins module is generalized, but it can be complex and slow.
• Conversely, pumakins is not very flexible, and writing custom kinematics modules for each new type of robot is quite tedious.

To bridge this gap, three21kins was ported from the gomotion repository, just like our other kinematics modules. I'm hopeful it would be of use to many 6-DOF arm + wrist style robot arms.

As a practical example, I have already switched my own robot arm to use this solver.

Please let me know if you have any feedback or suggestions!

[grandixximo]

Leaving it here for visibility, looks good to me, thank you

[grandixximo]

Two pieces of feedback looking at it again:

Docs: New kinematics modules are expected to show up in a few places; pumakins is a good template since three21kins follows the same pattern:

• A *loadrt three21kins* line in the SYNOPSIS and a === three21kins section in docs/src/man/man9/kins.9.adoc, describing the HAL pins (A1..A3, D1..D4, D6). Without this, users have to read the source to learn the pin names.
• A row in the kinematics table in docs/src/hal/components.adoc.
• An entry in the supported-modules list in docs/src/motion/switchkins.adoc, since the module implements the full switchkins setup.

NaN on unreachable targets (optional, non-blocking): In the inverse kinematics, both sqrt(sumSq) and sqrt(A3*A3 + D4*D4 - k*k) can receive negative arguments when the commanded pose is unreachable (or the wrist center falls inside the d23 cylinder). The result is NaN joint values returned with success status, and nothing upstream checks for NaN. Some hardening would be nice, for example clamping the sqrt arguments to >= 0 or returning nonzero so motion can report an inverse kinematics failure. I want to be clear that pumakins has the identical unguarded code and the gomotion original does too, so this is inherited behavior and in no way a blocker for this PR; consider it a suggestion for a follow-up improvement, possibly shared with pumakins.

[BsAtHome]

Is there a reason why you need to have the include file? It seems only used by this kinematics. You can just add the defined at the top here.

[BsAtHome]

You are using these several times in the code below. Reading these values is expensive because they are volatile.

Having these at the right time as a local version is cheaper and better for the compiler to optimize. But, you should be smart when and where which variables are required.