text: Title: Allow protocols to work on raw arrays
  Body: **Is your feature request related to a use case or problem? Please describe.**
  
  When working on #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 #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 https://github.com/quantumlib/Cirq/pull/7039#issuecomment-2645896832, 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?**
  <!-- Please choose one and remove the others -->
  
  P3 - I'm not really blocked by it, it is a suggestion based on principle 
  
  <!-- [optional] additional comment / context -->
  