(re)designing OperandsAndPartials and VectorView

[Bob Carpenter]

Rob and I pored over the existing designs yesterday and I
think there are a couple problems that stem from trying to
overload a single implementation to do different things rather
than writing separate implementations.

VectorView
----------

The functionality for arrays and matrices needs to be split
out so it can all live in the right place --- as is, it's
all in math/prim/meta/scal.

Do we really need to break meta out? Should it have its own
namespace, or just go into math? I think no and go into math.

This is a facade that unifies scalars, arrays, row vectors,
vectors, and matrices (though I'm not sure the latter makes sense).
It provides an operator[](int) implementation that returns a
T.

I'm not sure why it has a template parameter for is_vector_like.
This info is statically derivable from the template parameter T for
the wrapped type.

I'm also not sure why there's a throw_if_accessed. I'd think
if we want something to throw when accessed, we should give it
a different specialization for type T.

Next up, I think the way forward is to generalize so that the
contained type isn't necessarily scalar. It needs to be another
parameter S and then the critical interface is this one:

template <typename T, typename S>
VectorView<T, S> {
const S operator[](int x);
}

The current usage is for these instantiations, with U being
either a double or var or fvar<var> or fvar<fvar<var> >.

VectorView<U, U>
VectorView<vector<U>, U>
VectorView<Matrix<U, R, C>, U>

and if we need an auto-throw, then something like this:

VectorView<nil, U>

I think there should be three specialized implementations, not
just one with a conditional in the operator[]() implementation.

Then when we want to vectorize the multivariate stuff, we're
going to use things like sequences of vectors:

VectorView<Matrix<U, Dynamic, 1>, Matrix<U, Dynamic, 1> >
VectorView<vector<Matrix<U, Dynamic, 1>, Matrix<U, Dynamic, 1> >

and similarly for sequences of matrices. We only have two constructors
because you can't make a matrix of matrices (well you could, but Stan
doesn't require it, so we shouldn't bother coding it).

OperandsAndPartials
--------------------

I think the main issue here is that we want to split it into
several implementations. At the very least, I'd think we'd want an
fvar, var, and double version, though maybe var and double could
be combined?

Ideally it could be generalized to allow not just scalars to
be wrapped for derivatives, but also vectors and matrices. These
should all behave in exactly the same way (use the viewed interface
to update derivatives, with adding happening if they are broadcast).

- Bob