[MLIR + Frontend] Quantum Module Abstraction

[erick-xanadu]

trafficstars

Context: We create nested modules for qnodes that contain all the program for a specific qnode. This will allow us to perform transformations targetting specific qnodes.

Description of the Change:

• Adds catalyst.launch_kernel that can call functions in nested modules.
• Adds pass to keep previous behaviour by:
  • determining the name of a function given a scope
  • renaming all functions in nested modules to be unique
  • creating a map from flat symbol names to symbol names with path
  • inlining nested modules
  • transforming catalyst.launch_kernel to func.call

Benefits:

Nothing is currently using this pass / abstraction. But now we have the scaffolding for qnode specific transformations and lowerings.

Possible Drawbacks: More compilation time. Nested nested qnodes semantics are still needed. It was opted to disable tests with nested qnodes as they are not fully supported. Only nested qnodes where no qnode execution overlap was supported previously, but this is not the general case and could easily lead to runtime errors.

Related GitHub Issues:

TODO (minor changes):

• [x] cleaning up the frontend
• [ ] (optional) upstream changes to symbol table, to avoid patterns on gradient interface and zne.
• [x] use values from ctx.module_context instead of hard coded ones
• [x] can we avoid changing the order of functions as they appear? (This would help lit testing)
• [x] remove func_p?

[sc-67095]