We support both mutating and non-mutating propagators. Mutation is
better for large Hilbert spaces. Non-mutation is better for small
Hilbert spaces (`StaticArrays`!) or when trying to use automatic
differentiation.

There are some subtleties in finding the correct abstraction. It is not
as simple as using the built-in `ismutable` for states or operators and
making decisions based on that: Anytime we use custom structs, unless
that struct is explicitly defined as `mutable`, it is considered
immutable. However, we can still use in-place propagation, mutating the
mutable *components* of that struct.

Instead of overloading `ismutable`, we define the in-place or
not-in-place interface explicitly via the required behavior guaranteed
by the `check_state`, `check_generator`, and `check_operator` functions.

A new `QuantumPropagators.Interfaces.supports_inplace` function is
available to check whether a given `state` or `operator` type is
suitable for in-place operations.