Add FastAccelStepperEngine::moveAllToSync() for synchronized multi-axis moves

[ARDUTECH0]

Summary

• Adds FastAccelStepperEngine::moveAllToSync(steppers, targetPositions, count): starts several independent steppers, each to its own target position, so they all reach standstill at approximately the same time.
• This is not coordinated/interpolated motion - there's no enforced straight line between axes, and each stepper keeps running its own independent trapezoidal or S-curve ramp (setLinearAcceleration() still applies per axis). It only computes, per axis, how long the slowest axis' move would take at its own configured speed/acceleration, then scales every other axis' speed down (and, for moves too short to ever reach a scaled-down cruise speed, acceleration too) so all of them take the same time - never scaling anything up past what was already configured.
• Every stepper passed in must already have setSpeedInHz()/setAcceleration() configured; those become the per-axis ceiling for this call. A later, unrelated moveTo()/move() keeps using whatever values this call left behind, so reconfigure if the axis is moved individually afterwards.
• Includes a new example, examples/SynchronizedMultiMove, which drives two steppers with deliberately mismatched distance/speed/acceleration and prints (via millis()) how many ms after the shared start each one reaches standstill, so the synchronization is directly observable on the Serial Monitor without needing a scope.
• Regenerated extras/doc/FastAccelStepper_API.md via extras/scripts/header2markdown.sh and added the new keyword to keywords.txt.

Test plan

I have not been able to build or run this on real hardware or in the PC-based test suite - I don't have a compiler or a board available in the environment I wrote this in. The math (per-axis trapezoid/triangle timing model) is worked through by hand in the PR author's own testing notes, but has not been executed.

• Needs someone to actually build examples/SynchronizedMultiMove on real hardware (two motors on the StepperDemo-style pins is enough) and confirm both "reached standstill" log lines land close together despite the mismatched per-axis configuration.
• Would appreciate a maintainer/CI check against the existing test suite - no changes were made to the ramp generator or queue internals, this is built entirely on the existing public getSpeedInMilliHz()/getAcceleration()/moveTo() API, but that hasn't been verified by actually running anything.

[gin66]

Thanks for the patch.

I prefer to not include this in FastAccelStepper due to the following reasons:

• Heavy use of float
• Very special use case
• Looks more like an app solution.

Feel free to maintain your own fork of FastAccelStepper with this code included.