`CoordinateSystem` differed from `Field` in that its `GetData`
method returned an `ArrayHandleVirtualCoordinates` instead of
a `VariantArrayHandle`. This is probably confusing since
`CoordianteSystem` inherits `Field` and has a pretty dramatic
difference in this behavior.
In preparation to deprecate `ArrayHandleVirtualCoordinates`, this
changes `CoordiantSystem` to be much more like `Field`. (In the
future, we may change the `CoordinateSystem` to point to a `Field`
rather than be a special `Field`.)
A method named `GetDataAsMultiplexer` has been added to
`CoordinateSystem`. This method allows you to get data from
`CoordinateSystem` as a single array type without worrying
about creating functors to handle different types and without
needing virtual methods.
Marked the old versions of PrepareFor* that do not use tokens as
deprecated and moved all of the code to use the new versions that
require a token. This makes the scope of the execution object more
explicit so that it will be kept while in use and can potentially be
reclaimed afterward.
When creating the search structures in PointLocatorUniformGrid, a point
outside the boundary would be given an invalid bin id. These points
could never be found. Generally, this is not a big deal for points
outside of the boundary, but it could be a problem for points on the
boundary. A point on the boundary could be taken as outside the
boundary. Since the boundary is chosen from limits of the points, some
will almost always be on the boundary.
Fix this problem by clamping all points to the nearest valid bin. This
could cause a problem if the user has selected a boundary excluding a
lot of points. All those points could be grouped to the same edge bins,
but that is probably not a great idea anyway.
