ARModel: make interface use FluidTensorView

[weefuzzy]

Hello,

As discussed, updating interface of ARModel to use FluidTensorView rather than raw pointers, so that the sizes and offsets of the views could make it slightly easier to express / follow intentions w/r/t reading before pointers etc.

Bits of this you may find aesthetically objectionable. I've buggered about more with the little family of [model | forward | backward] [Error | Predict]() methods than originally imagined.

• I decided that I'd rather be able to assert in one place, so I've changed things so that the scalar functions are special cases of the array functions rather than vice versa,
• now comes down to specializations of modelPredict, which gets passed a different function object depending on whether it's doing a prediction or reporting an error. It probably warrants renaming.
• I've changed the ordering of params to inputs-then-outptus, because this is what we use everywhere else.

Personally, I'm happy that this is improvement in terms of readability and reason-about-ness, but then I'm (obviously) very comfortable with reading code with FluidTensorView manipulations in it. I do like that we need to be explicit about offsets and sizes at call sites, and that it's possible to drop assertions in pretty much throughout the call stack to ensure that assumptions about data before and after specific pointer locations are true.

After some false starts, it also passes the same (pretty lightweight) tests as the previous commit. (C++ equivalent tests still need updating...)