feat: Transversal overloads of builtin quantum operations

[rmfisher26]

Summary

• Overloads all builtin quantum gate commands (h, x, y, z, t, s, v, cx, cy, cz, tdg, sdg, vdg) to accept array[qubit, N] in addition to single qubit arguments
• Overloads measure, discard, and reset to also accept array[qubit, N], replacing the need for separate measure_array and discard_array calls
• Applies the same overloading pattern to the functional variants in guppylang.std.quantum.functional
• Adds backward-compatible aliases (measure_array, discard_array, reset_array) pointing to the internal array implementations
• Restores overload resolution logic in trace_call that is needed to correctly handle inout arguments for overloaded functions during comptime tracing

Motivation

• Closes Transversal overloads of builtin quantum operations #1078. Previously, applying a gate to an array of qubits required verbose iteration:

for i in range(n):
    h(qs[i])
for q in qs:
    discard(q)

Now users can simply write:

h(qs)
discard(qs)

Test plan

• New integration tests for single-qubit array operations (test_1qb_op_array)
• New integration tests for two-qubit array operations (test_2qb_op_array)
• New integration tests for measure and discard overloads (test_measure_overload, test_discard_overload)
• New integration tests for functional array variants (test_functional_1qb_array, test_functional_2qb_array)
• Existing quantum tests still pass (scalar usage unchanged)

Notes:
Error snapshots were updated for these 2 tests since now h was changed from a regular function to and overloaded one, However, I don't know if this is correct/intended behavior for these 2 tests:

• tests/error/modifier_errors/higher_order.err
• tests/error/poly_errors/non_linear2.err

[maximilianruesch]

Hi @rmfisher26, thanks for your ongoing work on guppylang! A note on the issue you have been working on: It seems like this issue has sparked controversy internally, and it is unclear what the best approach to address it is. This PR will thus have to rest until we have discussed this.

In the meantime, I recommend the following: Whenever you plan to work on an issue, comment and ask for relevance (as you have done in previous issues). Most issues older than a couple of months may be outdated / stale in some other way, or they have remained open since they sparked controversy (like this one). I have also tagged a few issues that are explicitly meant to be worked on, which you can find here (perhaps not the one that is S-blocked):
https://github.com/Quantinuum/guppylang/issues?q=is%3Aissue%20state%3Aopen%20label%3Ap-easy

That being said, we really do appreciate your commitment to improving the Guppy language, and we will welcome any additional PRs / suggestions you send our way, regardless of the status of this PR!

[rmfisher26]

Hi @rmfisher26, thanks for your ongoing work on guppylang! A note on the issue you have been working on: It seems like this issue has sparked controversy internally, and it is unclear what the best approach to address it is. This PR will thus have to rest until we have discussed this.

In the meantime, I recommend the following: Whenever you plan to work on an issue, comment and ask for relevance (as you have done in previous issues). Most issues older than a couple of months may be outdated / stale in some other way, or they have remained open since they sparked controversy (like this one). I have also tagged a few issues that are explicitly meant to be worked on, which you can find here (perhaps not the one that is S-blocked): https://github.com/Quantinuum/guppylang/issues?q=is%3Aissue%20state%3Aopen%20label%3Ap-easy

That being said, we really do appreciate your commitment to improving the Guppy language, and we will welcome any additional PRs / suggestions you send our way, regardless of the status of this PR!

Thank you @maximilianruesch for providing some more context about this and for your guidance. I will ensure next time that I confirm the work is relevant going forward. If there's an opportunity to return to this later on, I'd be glad to pick it back up!

[maximilianruesch]

Hi @rmfisher26, we had another look at this, and found that making these (naturally heavily used) functions overloaded would restrict them from being used as higher-order functions (see #1387 for some issues around that, it is non-trivial to resolve). Thus, it would be a pretty big breaking change to the language / allowed / compiling programs, and for that reason we will have to further defer this PR.

If you have any further questions just let me know!

[rmfisher26]

Thank you for taking the time to review this further and sharing your analysis. So, I do not have any further questions at this time. I hope the pull request in its current state was still beneficial to your team.