[jlee-kitware]

One resolver for field arguments; evaluated fields through filters and writers

Stacked on #299

Problem
Fields computed where they are read, such as field expressions from tack-expr, need three things from Tack:

• algorithms that take them by text;
• filter outputs that keep them;
• writers that store them.

Today a field argument is a Field or a stored name, filters carry such a field's placeholder values, and writers drop it.

Approach

• register_field_resolver(resolve): a field argument that names no stored field goes to resolve(data, text), which returns a Field or None. A bare name that matches no field is still a KeyError. tack-expr registers a resolver, so td.contour(data, "mag(U)", 1.0) contours an expression. Tack's filters take strings through this hook, and core never parses them.
• Filters carry a field's given gradient with it. An evaluated field is made again on the filter's output through its space's rebind, rather than having its values carried.
• dataset_to_vtk writes an evaluated field's values through its space's stored.
• An evaluated space may give default_subdivision, the number of lattice steps contour, clip and threshold cut its cells into. Contour shares points between cells for a continuous evaluated field.
• Derived fields: normals, measures and centroids are each one name. They are read at the location the reduction or expression asks for (points, cells or faces), and a field stored under the name comes first. They are computed from the mesh alone, shared by every dataset on that mesh, and made again only when the mesh changes. So integrate(surface, ["dot(U, normals)"]) is a surface flux with no filter first, and over many time steps the normals are computed once.

Verified
tack-vis on CPU and CUDA, including tests for the resolver (contour and gradients by text, a missing name still a KeyError) and for a given gradient carried through threshold. tack-expr's tests exercise the evaluated-field paths.