Python tests: check that the registration order doesn't depend on the fragment link order

[Fedr]

Adds a regression check for the deterministic registration order of the Python bindings, locking in the guarantees introduced by 236ba96 (deterministic topological type sort) and f2764c5 (deterministic alias ordering).

What it checks

The types and aliases are registered by static initializers, so their registration order across the fragment TUs follows the link order, and until the two commits above the bindings visibly depended on it: relinking the same objects in a different order moved the __init__ overloads injected from conversion operators (which affects pybind11's overload resolution), and shuffled the Aliases: docstring lines.

test/check_py_registration_order.sh:

1. generates bindings for test/order_check/input/MR/order.h — 8 classes with conversion operators into one Target class, plus 5 type aliases of it, deliberately spread across the file so that they land in different fragments (adjacent declarations would end up in the same fragment and could never shuffle);
2. compiles them as 4 fragments and links the same object files in two orders: 0 1 2 3 and 0 3 2 1;
3. imports both modules and requires their MRBIND_DEBUG=2 type/alias registration log, Target's docstring, and its __init__ overload list to be identical.

Status

• On current master the check passes: the full MRBIND_DEBUG=2 dump is byte-identical between the two link orders.
• On 236ba96 it failed on the Aliases: docstring line; before 236ba96 also on the type registration order and the injected __init__ overload positions:

-    3. __init__(self: example.MR.Target, arg0: example.MR.SrcCharlie) -> None
+    3. __init__(self: example.MR.Target, arg0: example.MR.SrcDelta) -> None

The branch history keeps the earlier implementation commits (now superseded by the master ones and reverted), so the net diff is just the check and its input.