Add Python device interface generator

[glopesdev]

Add a PythonGenerator class that produces a Python device interface module from device metadata, giving the generator set a third target alongside the existing C# and firmware generators. The generated module targets the register and payload DSL of the new pyharp unified API introduced in harp-tech/pyharp#5, so an existing device.yml can produce a ready-to-use Python interface with no hand-written register code.

The module mirrors the conventions of the pyharp hand-written reference:

• IntEnum and IntFlag types for group masks and bit masks.
• Payload classes for structured registers, using StructPayload with GroupMask, BitFlag, and Field descriptors, and for converter-backed registers, using AnonymousPayload.
• Register classes deriving from the appropriate Register* base, plus an address-to-class REGISTER_MAP. Application devices merge the core register map imported from harp.device.
• Enum member and payload field names in canonical Python casing, SCREAMING_SNAKE_CASE members and snake_case fields, produced through the same firmware naming convention used by the C firmware generator.

User-supplied converters are imported from a companion .converters module, the Python analog of the partial-method stubs the C# generator emits.

Validation

• Expected-output tests compare the generated core and device modules against committed reference files.
• A cross-stack interop test writes Harp binary frames through the generated C# interface, then reads them back through the generated Python interface to verify the two stacks agree on every public register. It runs via uv on the release CI legs, one per OS, so upstream pyharp changes that break cross-platform behavior are caught.

Notes

• This first pass emits the register and payload DSL only; package scaffolding is out of scope.
• The intermediate model types are internal, matching the C# and firmware generators, so the only new public surface is PythonGenerator and PythonImplementation.
• The output targets the in-progress pyharp unified API, currently pinned to a commit of the refactor-unified-api branch, so the interface may need adjustment as that API settles before a pyharp release.