docs: add a kinematics conventions chapter

[grandixximo]

A kinematics module reports the controlled point and nothing else, so everything that needs the rest of the machine geometry rebuilds it. For xyzacb-trsrn the same chain is written three times: closed-form in xyzacb_trsrn.comp, as homogeneous matrices in the config's remap_funcs_twp.py, and as signed HalRotate calls in the vismach model. The only thing keeping them in step is a comment in the Python saying its matrices "must be the same as the ones used to derive the kinematic model".

This adds a chapter writing down the vocabulary those three would need to share, so a second module can be written from the same drawing and give the same answers:

• the four frames, and that kinematicsForward() reports in the workpiece-attached one;
• the rotation sense, which is the one already stated under Rotational Axes in the G-code manual and is ISO 841's tool-relative-to-workpiece convention;
• what conventional-directions costs at its default of false, including that the rotary values come back as raw joint values while the translations in the same call use the flipped sign, so the returned pose does not describe its own orientation;
• the tool frame: tool z from tip towards holder, and tool x parallel to the machine xy-plane by default.

Tool x is stated as a rule rather than a formula on purpose. A five-axis machine cannot set rotation about the tool axis, so a virtual rotation supplies it, and the formula for the default follows from that machine's own secondary rotation matrix. The two nutating configs in tree have different formulas for that reason alone. Applying either to the other machine gives a frame turned a quarter turn, with the tool still pointing where it was asked to point, and nothing in tree would catch it.

Docs only. Also anchors the Rotational Axes section so it can be referenced.

Part of the multiaxis kinematics work in #4374, item 3. Independent of the rest of it.

[grandixximo]

Superseded by #4455, which carries this chapter together with the entry point it describes. The chapter names kinematicsToolFrame and TOOL_FRAME_FLANGE, so on its own it would have documented an API the tree does not have.