feat: Add customisable kv-pair metadata to gate definitions

[jake-arkinstall]

Allows additional arbitrary data to be provided along with a gate, for tracing execution and potential modification of behaviour (e.g. it is plausible that one may introduce a convention where gates tagged with "noise": false are noiseless).

Using this, we add preliminary support for gate tracking/debug workflows. When a QIS interface is in DIAGNOSTIC mode, we collect the __builtin_return_address on each QIS call and tag gates with it, and these appear in trace files output by Selene. A trace transformation is provided that uses the return address along with pyelftools/filebytes/symbolic to extract debug information for that address, which allows the stacktrace to be appended to each gate. If this information is preserved in the runtime and error model, we can identify which line of the user's program is responsible for which operation hitting the simulator.

[jake-arkinstall]

@cgh-qtnm this is my proposal for tracking debug information in 1.0-series, where gates are objects rather than functions.

We add arbitrary metadata to gates, and as long as this is preserved, we can trace that metadata through the entire workflow (user program -> runtime -> error model -> simulator). The return address for qis calls is an example of that kind of metadata.

[cgh-qtnm]

I don't see any architectural issues with this approach. One thing to note is that we will need to carry a dynamically-varying* number of backtrace frames (one u64 each) per gate for different applications, e.g. so we can trace through QEC libraries back to user code. This could be supported as a byte string, but it might be worth adding a first-class u64 array type (or a generic uint array type).

*at the shot or job level, not between gates in the same shot