[eudsl-llvmpy] MIR: allow multiple MachineFunctions in one hand-built module (create_machine_function makes exactly one)

Nobody has claimed this yet.

### Summary

The hand-built MIR API creates exactly **one** `MachineFunction` per `MachineModuleInfo`: `mir.create_machine_function(mod, tm, name)` builds a fresh `MachineModuleInfoWrapperPass` seeded with a single function, and `MirModule.machine_function(name)` only *retrieves* an existing function's `MachineFunction` (it does not create one). So there is no way to hand-build a module that contains two or more `MachineFunction`s and emit them together in one `emit_object` call.

### Why it matters

Several passes run per-`MachineFunction`, and their per-function behavior can only be exercised end-to-end with a module that holds more than one. Concretely, the Python register allocator (#644) constructs a fresh allocator instance in `runOnMachineFunction` — i.e. once per `MachineFunction`. With one function per module, "fresh per `MachineFunction`" and "fresh per emission" are indistinguishable, so the multi-function path can only be tested across two separate emissions rather than within a single pipeline run. The same gap applies to the scheduler and to anything else that keeps per-function state.

### Proposed change

Expose a way to add additional functions (each with a seeded `MachineFunction`) to an existing `MirModule`/MMI before `emit_object` — e.g. a `MirModule.add_machine_function(name, fn_ty=None, linkage=...)` that mirrors `create_machine_function`'s seeding but reuses the module's existing `MachineModuleInfoWrapperPass`, returning the new `MachineFunction`. Then a test can build two functions, emit once, and assert two distinct allocator/scheduler instances were constructed in a single pipeline.

### Acceptance

- A hand-built module can contain ≥2 `MachineFunction`s emitted in one `emit_object`.
- A regression test builds a two-function module and asserts the Python allocator constructs a distinct instance per `MachineFunction` within one emission.

Context: raised during review of #644.

Start with mir.create_machine_function, MirModule.machine_function(name), and emit_object to trace how the existing MachineModuleInfoWrapperPass is seeded and reused. Review the Python register allocator work from #644 and add a regression test that builds two functions, emits them together, and verifies distinct allocator instances are created per MachineFunction.

Written by the indexing model from the issue text.