Investigate `pyqir.SimpleModule` as return type instead of `pyqir.Module`

[ryanhill1]

In our functions cirq_to_qir and qasm3_to_qir, we currently return a pyqir.Module, which takes a "context" of type pyqir.Context and a "name" of type str. However, it might be worth considering whether we should return a pyqir.SimpleModule instead.

The pyqir.SimpleModule accepts a "context" object and "name," but it also requires an integer number of qubits, an integer number of results, and an optional entrypoint name (which defaults to "main"). Unlike pyqir.SimpleModule, the pyqir.Module does not store any entrypoint name. The qiskit_qir.to_qir_module() function returns a list of tuples containing entrypoint name strings and pyqir.Module objects. However, they could have instead just return a list of pyqir.SimpleModule objects, each of which would already have a .entry_point property.

Through our Cirq and OpenQASM 3 to QIR conversions, we can easily derive the values needed for the additional fields required to create a pyqir.SimpleModule. Furthermore, all the examples I’ve encountered (e.g., the pyqir README) indicate that pyqir.SimpleModule is the intended user-facing class, while pyqir.Module appears to be more of a low-level construct.

For instance, pyqir.SimpleModule.bitcode() supports Python type hints, whereas pyqir.Module.bitcode does not. The pyqir.SimpleModule also provides several user-facing methods that are not present in pyqir.Module. Furthermore, the pyqir.SimpleModule._module property ultimately returns a pyqir.Module, meaning that adopting SimpleModule would not lose any information.

Given these points, returning a SimpleModule instead of a plain Module seems like it would be a meaningful enhancement with minimal cost, aligning better with the intended usage patterns and providing additional functionality to users.