Descriptions: modifier (inv, ctrl, pow) Ops in the dialect has an associated (single-block) region. These ops have proper data flow tracking, i.e., subsequence quantum ops will take output of these modifier ops, not the wrapped instructions. The connection b/w the region-wrapped code and the op returns are handled by the quantum yield op (terminator for these modifier ops).

Lowering/optimization:

- If no optimization is required, these ops will be lowered to runtime (start/end) functions, identical to the current behavior. I need to separate part of this lowering (involves inlining the wrapped region into the parent region) to a individual pass, executed before the quantum-to-llvm dialect conversion b/c of some weird interactions with other dialect conversion patterns (e.g., qvs conversion) and type conversion. In some sense, when inlining the body, we are creating (cloning/copying) new MLIR Ops in the quantum dialect, so it needs to be executed before the whole quantum-to-llvm pass.

- If optimization is turned on: when possible (e.g., the wrapped code only contains qvs ops), it will resolve the modifier at compile time: reverse gates for inv, derive the ctr-gates, rewrite pow->for loops.

Modifiers that cannot be optimized will remain and  be handled by the lowering step above.

Added tests. There is an edge case that this doesn't cover is compute-action. I retain the existing behavior by directly calling runtime functions. Hence, the SSA tracking in this use case is not reliable for optimization.

Signed-off-by: Thien Nguyen <nguyentm@ornl.gov>