coverage: 87.741% (+0.01%) from 87.729%
when pulling 52264ce on Ericgig:feature.dtype_range
into eb3e5c4 on qutip:master.

@nwlambert
I tried to address the issue of defautl dtype not being apply where expected here.
It probably won't affect the brmesolve issue but I would like you opinion on the approach.

thanks eric, I like the option of creation and full. Took me a moment to understand the meaning of the ''missing'' option. is there some clear situation where someone would use this? perhaps there is a better name too?

for default_dtype_range, how about default_dtype_scope?

i will try and play with the PR, see if it does what i would expect

I don't think either "missing" or "full" should be used much with pure qutip. Only with plugins like qutip-jax it makes any sense to me. With "missing", you could set it so it will end up all in jax format and not have too much issues.

"full" will probably break HEOM, some steadystate feature, slow down scipy integrators, etc. "missing? should be safe.

Ok for default_dtype_scope.

I had a quick play with the feature, for the cases I had stumbled on before, with `eigenstates()' ignoring default_dtype, using the scope of 'full' covers it now. I understand having this work with just 'creation' scope is problematic because you want to make sure the dtype is not used on results lists.

heom+full breaks with dia and dense, as expected!

speaking of heom, manually converting the RHS to jaxdia and doing stuff it worked fine. i think generalizing the RHS construction in heom away from csr is probably very difficult without huge performance drop in the construction, so perhaps some kind of wrapper or option to do conversion of types after construction would be fine?

I tried running tests with scope=full and it has priority over manually entered dtype values...
Not that using object in those other type is really possible with that options, it still not great.

For the HEOM, perhaps the HEOM solver could gain an option to select the dtype to convert the RHS to?