Add hierarchical qubit types

[joeycarter]

Context: Catalyst currently only supports a single, universal qubit type in its MLIR program representation: !quantum.bit. In order to express FTQC workloads in the compiler, we require a more expressive type system to represent a program that is successively lowered from the user program to a hardware-agnostic QEC layer and to a hardware-specific error-corrected MBQC physical layer. We also anticipate that the definitions of these new types will simplify the implementation of a number of other components in the FTQC software stack, especially those that operate at multiple levels of qubit-type abstraction, such as a Pauli frame tracking system.

Description of the Change: This change introduces the following qubit levels:

• !quantum.bit<abstract>
• !quantum.bit<logical>
• !quantum.bit<qec>
• !quantum.bit<physical>

The abstract level is the default and is equivalent to !quantum.bit. In addition to the qubit level, the following qubit roles have been defined to specialize the qec and physical qubit types: null, data, xcheck and zcheck. These roles are represented in the IR as, for example:

• !quantum.bit<physical, null>
• !quantum.bit<physical, data>
• !quantum.bit<physical, xcheck>
• !quantum.bit<physical, zcheck>
• etc.

The null role is the default for all levels and can be omitted. The purpose of the role parameter is to distinguish data qubits and syndrome qubits to extract X and Z corrections in CSS QEC codes by way of stabilizer measurements. As such, the IR restricts these role parameters to the qec and physical qubit types; abstract and logical qubits currently do not permit specifying a role other than null.

To allow for correct type parsing while continuing to use the custom assembly format that quantum operations use, all quantum ops that consume and return qubit values are now restricted to input and output qubits of the same type. This restrictions is accomplished by adding AllTypesMatch<["in_qubit", "out_qubit"]> traits to the appropriate quantum operations. This restriction means that operations such as

%0 = ... : !quantum.bit<logical>
%1 = ... : !quantum.bit<physical>
%2 = quantum.custom "..."() %0 : !quantum.bit<logical>
%2 = quantum.custom "..."() %1 : !quantum.bit<physical>

are permitted, but operations that mix types, such as

%0 = ... : !quantum.bit<logical>
%1 = ... : !quantum.bit<physical>
%2 = quantum.custom "..."() %0 : !quantum.bit<qec>
%3, %4 = quantum.custom "..."() %0, %1 :  !quantum.bit<logical>, !quantum.bit<physical>

are not.

Benefits: More expressive IR for FTQC workloads; simplifies implementation of compilation passes that convert between levels of abstractions.

Possible Drawbacks: The details of the compilation passes that convert a program to the QEC and physical layers are still being established, therefore the requirements for these new qubit types may change as these future passes develop.

[sc-107427], [sc-107428], [sc-107429], [sc-107430], [sc-107433]