Optimize measurement_key methods

[95-martin-orion]

Measurement keys of circuits and operations are referenced in the circuit construction process. Unfortunately, the methods for extracting measurement keys can be slow, especially in the presence of subcircuits, classical controls, and other complexity. We should see what we can do to speed these up and improve the circuit construction experience.

Highlighted in #4040.

[daxfohl]

It looks like most of what can be done is already done here. Expensive lookups are about as fast as they can be, and cached where possible. The remaining issue is the protocols. In particular, measurement_key_objs tries four different magic methods before returning an empty set (which is the most common case). A few options here.

1. Implement _measurement_key_objs_(self): frozenset() explicitly in all non-measurement gates, which prevents the protocol from trying subsequent methods. This is already done in EigenGate, so the most common gates are handled. But it'd have to be implemented in lots of gates, and they should implement _measurement_key_names_ etc., so a lot of boilerplate. And 3rd-parties would have to do the same to their own custom gates to get the same effect.
2. The obvious next thought is, we should implement _measurement_key_objs_(self): frozenset() as the default in Gate. This would be a breaking change though. MeasurementGate implements _measurement_key_obj_ (singular) instead, which the protocol checks for if the plural one is unimplemented. However if we update the base class, the plural one will return the empty set, and it won't check the singular. This would be the case for PauliGate, KrausChannel, and any 3rd-party measurement gates.
3. Probably what I'd recommend is getting rid of the protocol entirely. Instead, create an interface that has a measurement_keys() function and implement that for Gates, Ops, Circuits, and Moments. Protocols are good for when there are different possible ways of implementing something, but here it's just a function that returns a list.

[daxfohl]

The challenge with 3 is that other protocols depend on measurement keys (some implementations of _commutes_ and _act_on_fallback_). Since protocols operate on Any, it's not particularly safe to call an interface method from them, as the thing may not implement that interface.

The solution would be to lift those up to the interface as well. This kind of makes sense; Ops, Circuits, and Moments are all similar, maybe a CircuitComponent interface that has measurement_keys, commutes, and act_on. Gates are slightly different in that they can't check commutativity or be acted on without knowing the qubits. But that's fine, they can still implement the HasMeasurementKeys interface.

Anyway, that all ends up being a pretty big change. It wouldn't be worth the benefit of measurement key perf alone. If we want to consider it, then it's more of a "change unnecessary protocols into interfaces" roadmap item. IDK if that's something anybody really wants to do though.

I'd say we should probably close this issue. I don't see much of value that can be done here.