Add dtype to QobjEvo and use it in qeye_like

[Ericgig]

Description
qzero_like used on QobjEvo would call it (it needed qevo(0).data), which is both slow and could break jax.jit.
I added Qobj.dtype and QobjEvo.dtype to be used instead of accessing the data directly.
For QobjEvo, the dtype property still call the object when the type is unclear (mixed or function based), but it should be faster otherwise.
Tested that the example in qutip/qutip-jax#33 works.

[coveralls]

coverage: 85.814% (+0.006%) from 85.808%
when pulling fa3a073 on Ericgig:misc.evo_like_support
into 4f6231a on qutip:master.

[hodgestar]

While reading qutip/qutip-jax#33 I was wondering whether we should allowed mixed-dtype QobjEvos at all. I'm struggling to think of a case where it is what a user would want and can imagine lots of situations where it would not be what anyone wanted.

[Ericgig]

It would be hard to enforce since we accept functions returning Qobj.
If someone passed dtype in args, there is nothing we can do.
Also since the most common use case is part @ state, they don't interact much together and each part can be optimized for it's sparsity without issue.

Mixed case are not that rare. Per default sigmax is CSR and qeye is Dia and I can't say what is sigmax & qeye without checking. So QobjEvo([sigmax(), [qeye(2), f]]) mixes CSR and Dia.
How do we decide which one we quietly transform? Everything else just work with whatever type is used. So we can't have this raise an exception.

Personally I think we should only mix in a family of dtypes, Dense, Dia and CSR can be mixed, but no mixing of jax with CSR, etc. But we don't have what we need to enforce it.