Add Python interface generator command

[glopesdev]

Exposes the Python device interface generator added in Harp.Generators 0.6.0, which reached the toolkit in #33 but had no command line to invoke it. The language becomes an optional subcommand of generate interface, so the published invocation keeps working and generating the .NET interface exactly as before.

Usage:
  harp.toolkit generate interface [<metadataPath>] [command] [options]

Arguments:
  <metadataPath>  The path to the file describing the device registers. [default: device.yml]

Options:
  -ns, --namespace <ns>  The namespace for the generated code. The default is `Harp.DeviceName`.
  -o, --output <o>       Location to place the generated output. The default is the current directory.

Commands:
  csharp  Generate reactive programming API and async API. This is the default.
  python  Generate the Harp Python device interface.

The csharp subcommand generates the same two files the bare command does, so it exists to say explicitly what the default already does rather than to add behavior.

The consequence worth reviewing is token order. The metadata path is given before the language, so generate interface device.yml python works and generate interface python device.yml reports an unrecognized argument. --namespace and --output work on either side of the language token.

PythonGenerator takes no namespace, so --namespace applies only to the .NET interface. Rather than accept and ignore it, the python subcommand rejects it through a validator.

Documentation

The README gains a code generation section naming both targets, and the interface section of the code generation article is restructured. The description of what a generated interface contains, a type per register with its enum and payload types and a map from address to type, is now stated once, with ### .NET interface and ### Python interface as subsections carrying only what differs.

The output location option, which every generation command accepts identically, is also stated once as its own section instead of being repeated under each command. That removes four blocks whose headings collided on the same anchor.

Both targets are named by the library they are built on rather than by the language alone, Bonsai.Harp and Harp Python, since the generated .NET code requires Bonsai.Harp and therefore Bonsai.Core. The subcommands stay csharp and python, since the command line axis is the language while the documentation carries the dependency.

Verification

Verified against the Behavior device metadata. Both .NET paths, the bare command and csharp, produce output byte-identical to the two generated files harp-tech/device.behavior has checked in, so the default path is unchanged. The generated device.py is 1258 lines carrying 172 classes, imports from harp.protocol and harp.device.core, declares DEVICE_NAME and REGISTER_MAP, and parses cleanly as Python. Every command shown in the readme and the article was run as written.

Closes #29

[bruno-f-cruz]

Tested from the build with a couple of devices, and everything seems to be working.