Implement pyqrack methods for squin noise statements

[david-pl]

          LGTM can we have some basic tests on the constructors? Or maybe you could help @david-pl add the corresponding runtime in a new PR (which should test this too). I think would be nice to have it before next week's hackthon.

Originally posted by @Roger-luo in #211 (review)

[weinbe58]

implement a single runtime statement for pyqrack and then rewrite common noise channels to this statement :

@statement(dialect=dialect)
class StochasticUnitaryChannel:
    operators: ir.SSAValue = argument(ilist.IListType[OpType, NumOperators]
    probabilities: ir.SSAValue = argument(ilist.IListType[float, NumOperators]

This statement models a channel where the application of this channel corresponds to selecting an operator in operators with probability probabilities and then applying this operator on the state.

All the Pauli channels boil down to this kind of channel operation.

[david-pl]

@weinbe58 working on #273 and now I'm wondering:
Do we even want the rewrite? In the squin runtime, we have to create a runtime object for operators anyway. So I could just as well give the statements a common interface, e.g. get_operators and get_probabilities getter methods (or just properties?) and use those to create a single common runtime object for all of them.

IMO, that would be easier, results in less code and is a bit clearer since the IR keeps the original statements.
Is there any reason why we should prefer the rewrite?

[david-pl]

@weinbe58 to clarify what I mean, I drafted something up in #278. The runtime is the same, the method table is still just one method, basically:

bloqade-circuit/src/bloqade/pyqrack/squin/noise.py

Line 14 in 33f1073

def stochastic_unitary_channel(

Instead of the rewrite, I'd be adding common methods to the noise statements.

I'd argue that this approach is a bit simpler, but I'm sure you have some better insights, so I'd like to know which approach you prefer before continuing.