Allow simulator quantum state representations to be used in qis

[daxfohl]

This PR unifies the quantum state types between sim and qis modules.

We create a HasQuantumState interface, from which both QuantumState and ProductState (used in qis), and QuantumStateRepresentation (the base class of quantum states used in simulators, including CliffordTableau, MPS, CHForm, SV/DM) inherit.

We then update the relevant qis method parameters to use HasQuantumState instead of QuantumState. This allows a broader range of quantum state representations to be analyzed in our qis utilities.

xref #4582

[95-martin-orion]

What all does this actually buy us? I assume qis makes use of QUANTUM_STATE_LIKE in several places, and that's how this gets distributed? OTherwise it seems like only von_neumann_entropy is benefiting from this.

[95-martin-orion]

Keeping this here seems wrong - density matrices should override it, and everything else can call the parent method.

[95-martin-orion]

Mixed feelings on this name - I'd expect "Has..." to be a method, intuitively. Is AbstractQuantumState already taken?

[daxfohl]

@95-martin-orion Perhaps it's not useful. I'm mostly looking at #4582, which seems to be asking for some unification between various types of quantum states allowing them to be used in qis independently, and then a state function that can create the best type. This PR provides the first part of that, and makes the second part much easier.

Admittedly when I started this I assumed qis was much richer than it is and that this would be a valuable addition. But, yes currently this only applies to von_neumann_entropy and fidelity, which is rather disappointing. Though I'm pretty happy with how the new unit tests look (though whether anyone would actually use the functionality like that, IDK)

I still think it's a nice unification for the sake of unification, but we should probably sync with @viathor and see if this is what he had in mind for #4582 next cynq. I'll re-mark this as draft until then.

[daxfohl]

@95-martin-orion The other consideration is I remember a while ago there was a proposal to adopt some existing qis library. That may actually make sense here. The only real core thing in qis seems to be the to_valid_stste_vector/density_matrix functions that we could just move to linalg. (I believe the implementation of those could be simplified a bit too. Or, it's likely that quimb or whatever has equivalents.) But beyond that, the qis module seems pretty sparse and unmaintained, and not really integrated with anything else.