custom AD transform plugin: a use case from YaoCompiler

this is just one thing I was waiting Diffractor to think about, it comes from the idea of integrating Diffractor and YaoCompiler, I'll leave a description of what we want to do on this here, I assume this could be similar for GPUs too, since the design of SSA IR can be seen as MLIR regions too.

in a quantum program, there are certain AD rules that makes use of the reversibility and (quantum specific) algebra rules, such as Pauli operators etc.
As a result there are three ways of doing AD on a quantum program

1. parameter shift rule: forward mode AD, works on hardware, but on pure quantum circuits that satisfy the Pauli operator permutation rule
2. reverse mode using circuit reverisbility: reverse mode, but only runs on simulator, the register (quantum state vector) will always be mutated to save memory (thus has side effect)
3. transform the circuit to an integral of channel: forward mode, works on hardware, works on broader set of operators, but will create a hybrid program (may contain classical control flow)

these can be implemented on a pure quantum program without touching compiler transform, which we can do in short term, but
the problem becomes different when the program contains classical control flows (the long term goal),
which is one feature we aim to support in YaoCompiler - compile a general Julia program to quantum hardware,
in YaoCompiler, we extend Julia SSA IR to contain two new elements in the SSA IR:

1. a quantum block: like basic block, but only contains quantum instructions/statements, this block is always inside a basic block
2. a quantum terminator: statement that jump from a quantum block to a basic block

(I wish I could post a picture of this, but I don't have one at the moment)

so then the idea is to tell an AD compiler like Diffractor to know how to transform a piece of program like this using a plugin, or re-use Diffractor's transformation in another compiler plugin for the irrelavent part (for the quantum case, is to run Diffractor on classical statements, but run a custom pass on the quantum components above) but I'm not sure if this is the best way of doing it. And I think with the work of julia compiler plugin there would be more cases like this that someone may want to have a custom AD plugin used by Diffractor when differentiating under their compiler plugin context.

I guess some other folks might be interested in this, cc: @aviatesk @femtomc

No files, tests, or entry points are named. Start by clarifying how Diffractor should interact with YaoCompiler's Julia SSA IR, including quantum blocks and quantum terminators, and define the plugin boundary and expected behavior for classical versus quantum components before implementation can be scoped.