Compatibility with DifferentialEquations.jl

Right now, this package is not compatible with the RecursiveArrayTools.jl package used by DifferentialEquations.jl.

e.g. here is a simple example from the DifferentialEquations tutorial, modified to use a `TupleVec(dx, [dy, dz])` of a scalar and a vector:
```jl
using DifferentialEquations, TupleVectorSpaces

function lorenz(u, p, t)
dx, (dy, dz) = Tuple(u)
dx = 10.0 * (u[2] - u[1])
dy = u[1] * (28.0 - u[3]) - u[2]
dz = u[1] * u[2] - (8 / 3) * u[3]
TupleVec(dx, [dy, dz])
end

u0 = TupleVec(1.0, [0.0, 0.0])
tspan = (0.0, 100.0)
prob = ODEProblem(lorenz, u0, tspan)
solve(prob, Tsit5());
```
This gives the error:
```jl
MethodError: no method matching ndims(::Type{TupleVec{Tuple{Float64, Vector{Float64}}}})
The function `ndims` exists, but no method is defined for this combination of argument types.

Closest candidates are:
ndims(::Type{Union{}}, Any...)
@ Base abstractarray.jl:276
ndims(::Type{<:AbstractVectorOfArray{T, N}}) where {T, N}
@ RecursiveArrayTools ~/.julia/packages/RecursiveArrayTools/Y3i0V/src/vector_of_array.jl:595
```

Although it would technically be possible to support indexing into a `TupleVec`, i.e. to make it act like an `AbstractVector`, I'd really rather keep it more general and represent an element of an arbitrary normed vector space. I don't see any fundamental technical reason why this shouldn't be compatible with numerical ODE solvers (just as it's already compatible with numerical integration).

@ChrisRackauckas, is there a way to tell RecursiveArrayTools not to try to "look inside" a `TupleVec`, and instead treat it as an opaque mathematical object? As long as we're not trying to work in-place, at least for explicit solvers I don't see why you should need to look inside the vector.

Beginne damit, das Lorenz-Beispiel von DifferentialEquations.jl mit TupleVectorSpaces nachzustellen und den gemeldeten RecursiveArrayTools-ndims-Fehler zu reproduzieren. Untersuche, wie RecursiveArrayTools TupleVec behandelt und wie das Paket beliebige normierte Vektorräume darstellt; die Arbeit ist abgeschlossen, wenn das Beispiel des expliziten Solvers läuft, ohne dass sich TupleVec wie ein AbstractVector verhalten muss.

Vom Indexierungsmodell aus dem Issue-Text verfasst.