Allow protocols to work on raw arrays

[WingCode]

Copied from quantumlib/Cirq #7050

Is your feature request related to a use case or problem? Please describe.

When working on quantumlib#7048, was surprised that unitary(val) and apply_unitary(val, args) didn't accept raw numpy unitaries for val. This made it necessary to special case a couple isinstance(np.ndarray) checks in the consumers of those functions. There is also an already-existing redundant function in apply_mixture that can be removed if apply_unitary can accept raw numpy unitaries. If accepted, this could be a good first issue for someone.

Describe the solution you'd like

I started this for apply_unitary in quantumlib#7039, but closed the PR because a) I think it's a maintainer decision as to whether the feature is desired, how large the scope should be, and whether it can be delivered incrementally or should go all-at-once, and b) I think it would be a good first issue for someone to learn about quantum operators in general, and cirq's implementation of protocols in particular.

As mentioned in the closing comment quantumlib#7039 (comment), the scope is open-ended.

Closing for now. Seems like if we do this, then we should also do unitary and has_unitary. Which, then may as well do mixture and kraus series, maybe act_on, and whatever else comes up too. Support raw Python arrays? Sympy?....

[optional] Describe alternatives/workarounds you've considered

Duplicate code, instanceof checks.

[optional] Additional context (e.g. screenshots)

As part of this, I noticed the protocols have different techniques. Some loop through an array of strategies, others are more imperative. Some use dynamic invocations of the fallback strategies, whereas others call the fallback protocols directly. It'd be good to improve consistency in these when working through them.

What is the urgency from your perspective for this issue? Is it blocking important work?

P3 - I'm not really blocked by it, it is a suggestion based on principle