Make material property, boundary condition functions vectorizable

[jeff-cohere]

@jedbrown has suggested in #195 that we modify the signature of the functions we have been using for material properties and boundary conditions to accept an array of input positions and populate an array of outputs. Specifically, we want to change from a "single-point evaluation" approach, e.g.

f(tdy, x, v, ctx)

to a multi-point evaluation approach:

f(tdy, n, X, V, ctx)

In the single-point approach,

• f is one of these functions
• tdy is a TDy object passed as the first argument
• x is a pointer to a 2- or 3-tuple of real numbers identifying a point in 2D or 3D space
• v is a pointer to a real value that stores the (scalar) value of f
• ctx is an opaque pointer that stores any additional contextual information needed by f

The multi-point approach replaces x and v with

• n, an integer defining the number of points at which to evaluate f
• X, an array of 2*n or 3*n values defining n 2D or 3D points, with components stored adjacently
• V, an array of n values that store each of the n values of f at the points given by X

This is a pretty easy thing to do and will probably buy us some performance.

[jedbrown]

Note that this is consistent with the formulation we use in libCEED. Usually one does this in batches that fit conveniently in cache. I don't know if it's a bottleneck at present, but if the material models become expensive, we'll want them to vectorize. Note that some special functions (log1p in our hyperelasticity work) are not vectorized by default with gcc/clang. (For log1p in libCEED, we implemented a series expansion that delivers the necessary accuracy over reasonable input range, though one can also use libraries like SVML.)