motion: per-axis homed check for teleop jog soft limits

[grandixximo]

Fixes #182 (and its duplicate #224).

Problem

An unhomed machine jogging in teleop mode is clamped to the INI soft limits as if its position were 0: at X0 with MIN_LIMIT=-10 the jog stops at -10 although the true position is unknown. Joint jogs got this right in 2006 (refresh_jog_limits): unhomed jogs one limit range from the current position, homed uses the INI limits.

Only identity kinematics can enter teleop unhomed, and the usual routes never exercise it: AXIS and gmoccapy stay in joint mode until homed, so their unhomed jogs are joint jogs and already behave. What is affected is an axis jog source wired straight to motion: a panel on the halui axis pins with NO_FORCE_HOMING=1, jogging near the home switches before homing, or a script that teleop_enable(1) first. That panel setup is less rare than one might imagine.

Fix

Axes are not homed, joints are, so the check is per axis: an axis is homed when every joint mapped to its coordinate letter is homed. A gantry letter needs all its joints homed before its INI limits apply; homing Z alone gives Z its limits while X and Y still jog one limit range from wherever they stand.

The letter-to-joints map is the one identity kinematics already build from the coordinates parameter (kins_util.c), exported as identityKinematicsAxisJointsBitmap() instead of re-derived in motion. Modules without a map report 0 and fall back to all-homed, which teleop guarantees for them, so non-identity kinematics are unaffected. Homed axes behave exactly as before; for an unhomed axis the servo-cycle INI check in update_teleop_with_check() is skipped, since its position is not known.

Tested

sim/axis, X limits ±10, Z limits -8..0.12, jogged via halui axis pins with NO_FORCE_HOMING=1 and via scripted teleop jogs (same motion path):

AXIS jog -X unhomed          -20.00  (master: -10.00, the bug)
home Z only
AXIS jog +Z homed              0.12  (INI limit)
AXIS jog -Z homed             -8.00  (INI limit)
AXIS jog -X still unhomed    -20.00  (pos +/- range)

plus the tests/motion suite (5/5).

Compatibility

The accessor is a weak symbol in motion: kinematics modules that do not link kins_util.c (matrixkins, out-of-tree modules built on older headers) load and run exactly as before, answered by the all-homed fallback. No rebuilds required.

Note for the post-NML work

"Which joints are which axis letter" is re-derived all over the tree: gmoccapy re-parses [KINS]KINEMATICS in Python, AXIS applies lathe/trivkins heuristics, qtvcp reads [TRAJ]COORDINATES, and each guesses wrong on gantries or reordered coordinates in its own way. The map exported here is the natural single source. Whatever replaces NML should carry the joint-to-axis map to task and the UIs, built from this same kins-side data, so the GUI-side re-implementations can be deleted. This fix does not depend on that; motion runs in RT and needs the map where the kinematics module already has it.