Introduce multi-ranges and use views for operator splitting

[termi-official]

Currently we copy (and hence duplicate) solutions between integrators in operator splitting procedures. However, we could work on views instead, which should reduce the memory overhead quite a bit.

[kylebeggs]

So just to make sure I understand this issue completely - using the parlance from https://termi-official.github.io/Thunderbolt.jl/dev/topics/time-integration/ suppose we have two subproblems, $F_1$ and $F_2$, where $F_1$ has $N_1$ elements and $F_2$ has $N_2$ elements. We wish to be able to have a single parent solution vector, $u$, which is $N_1 + N_2$ elements in length and so when we solve problem $F_1$ we can pass just $u_1$ which a view of $u$ that corresponds to the $F_1$ problem? I tried looking through the code and don't see where the copies happen, can you link to those lines on the source code?

[termi-official]

Thas is kinda the rationale. Just that we usually can't pass views of u around, but for other objects like e.g. uprev. However, the tricky part is actually that, in general, F1 and F2 overlap.

A major incompatibility between OrdinaryDiffEq and Thunderbolt stems from the order of responsitiblity. In both frameworks init passes (Thunderbolt just sometimes) objects like u and uprev into the algorithm cache constructors. Thunderbolt now assumes that the cache holds the real solution vector type u, uprev, ... while in OrdinaryDiffEq assumes that the one passed into the cache is the real vector.

See e.g.

Thunderbolt.jl/src/solver/operator_splitting/solver.jl

Lines 25 to 26 in 016a8d2

	_uprev = alias_uprev ? uprev : SciMLBase.recursivecopy(uprev)
	_u = alias_u ? u : SciMLBase.recursivecopy(u)