Move `ParameterVector` to Rust

[jakelishman]

We currently have a Python object (ParameterVector) deeply nested inside a core Rust data type (ParameterExpression -> Symbol). Since ParameterVector is frequently used in library circuits, this means we inadvertently have Python objects buried much deeper than we expect, which a) makes us slower than we should be and b) makes it easier to violate panicking contracts in simple Clone operations (e.g. #16053).

We need to make ParameterVector a core Rust object to avoid this in the future.

Chain of PRs to fix this issue:

• Make uuid public on ParameterVector #16216
• Use ParameterVector(uuid=...) in QPY deserialisation #16221
• Remove QPY warning on deserialising incomplete ParameterVectors #16222
• Move ParameterVector to Rust #16228

[Cryoris]

What do we gain again from the backreference of the ParameterVectorElement to it's parent ParameterVector? I was hoping to keep this out of Rust and the C API, since that seems overly complicated and the main use came from sorting elements according to an index.

[jakelishman]

In Rust we actually gain a ton, because we can avoid storing the same String over and over and over again - we can cheaply generate the concrete objects on the fly.

[jakelishman]

Just as a brief preview, it lets us easily swap to this:

#[derive(Debug, Clone, PartialEq, Eq, Ord, Hash)]
pub enum Symbol {
    Standalone {
        name: String,
        uuid: Uuid,
    },
    Element {
        index: usize,
        base: Arc<SymbolVector>,
    },
}

instead of a String and Uuid per vector element and the same string being stored in the vector and re-computed.

This comes at the cost of not being able to faithfully round-trip very very old circuits in QPY that allowed disconnected UUIDs for vector elements, but I think that's a reasonable trade-off.

[Cryoris]

Ah ok in this case we'd get a performance improvement from the backref 👍🏻 but I thought there were also some technical requirements on where the backref was used? 🤔

[jakelishman]

Julien: turns out there's a few reasons why we need a backref of some sorts - if nothing else, we need to keep one around so we can generate a Python-space ParameterVectorElement, and that needs one. I've just updated the head comment of this issue with the now-complete chain of PRs that closes it.