The external faces filter was not working with curvilinear data. It was throwing
an exception about not being able to cast the coordinates array. This has been
fixed to work with this condition.

The external faces filter was not working with curvilinear data. It was throwing
an exception about not being able to cast the coordinates array. This has been
fixed to work with this condition.

Previously, the Marching Cubes contouring algorithm only had case tables for 3D
polyhedra. This means that if you attempted to contour or slice surfaces or
lines, you would not get any output. However, there are many valid use cases for
contouring this type of data.

This change adds case tables for triangles, quadrilaterals, and lines. It also
adds some special cases for general polygons and poly-lines. These special cases
do not use tables. Rather, there is a special routine that iterates over the
points since these cells types can have any number of points.

Note that to preserve the speed of the operation, contours for cells of a single
dimension type are done at one time. By default, the contour filter will try 3D
cells, then 2D cells, then 1D cells. It is also possible to select a particular
cell dimension or to append results from all cell types together. In this latest
case, the output cells will be of type `CellSetExplicit` instead of
`CellSetSingleType`.

A problem we have with the `vtkm::Swap` method is that it can be
ambiguous with the `cub::Swap` method that is part of the CUDA CUB
library. We get around this problem by using the CUB version of the
function when it is available.

However, we were missing an include statement that necessarily provided
`cub::Swap`. This function is now explicitly provided so that we no
longer rely on including it indirectly elsewhere.

Thanks to Jens Goebbert for this fix.

Calling `vtkm::cont::Initialize()` is supposed to be optional. However, Kokkos
needs to have `Kokkos::initialize()` called before using some devices such as
HIP. To make sure that Kokkos is properly initialized, the VTK-m allocation for
the Kokkos device now checks to see if `Kokkos::is_initialized()` is true. If it
is not, then `vtkm::cont::Initialize()` is called.

Calling `vtkm::cont::Initialize()` is supposed to be optional. However, Kokkos
needs to have `Kokkos::initialize()` called before using some devices such as
HIP. To make sure that Kokkos is properly initialized, the VTK-m allocation for
the Kokkos device now checks to see if `Kokkos::is_initialized()` is true. If it
is not, then `vtkm::cont::Initialize()` is called.

The `constexpr` keyword is helpful to add to functions and macros where
possible. Better than `inline`, it tells the compiler that it can perform
optimizations based on analysis of expressions and literals given in the
code. In particular, this should help code that loops over components have
proper optimizations like loop unrolling when using `Vec` types that have
the number of components fixed.

We have run into issues with the `nvcc` compiler giving shadow warnings for
the internals of thrust like this:

```
/usr/local/cuda/bin/../targets/x86_64-linux/include/thrust/detail/internal_functional.h: In constructor 'thrust::detail::unary_negate<Predicate>::unary_negate(const Predicate&)':
/usr/local/cuda/bin/../targets/x86_64-linux/include/thrust/detail/internal_functional.h:45:46: warning: declaration of 'pred' shadows a member of 'thrust::detail::unary_negate<Predicate>' [-Wshadow]
   explicit unary_negate(const Predicate& pred) : pred(pred) {}
                                              ^
/usr/local/cuda/bin/../targets/x86_64-linux/include/thrust/detail/internal_functional.h:42:11: note: shadowed declaration is here
   Predicate pred;
           ^
```

These warnings seem to be caused by the inclusion of `thrust/swap.h`. To
prevent this, this header file is no longer included from `vtkm/Swap.h`.

Historically, `needs` specifies the jobs which need to complete
successfully and `dependencies` specifies the jobs which provide
artifacts which should be used. Modern GitLab discourages using both as
`needs` now supports an `artifacts` key to say "depend on but do not use
artifacts", so remove `dependencies` and use `needs:artifacts` where
necessary.

See: https://docs.gitlab.com/ee/ci/yaml/#needsartifacts

Apparently, starting with LLVM clang version 20, if you use the `template`
keyword to highlight a sub-element, you have to provide a template argument
list. This is true even for a method where the template arguments can be
completely determined by the types of the arguments. Fix this problem by
providing an empty template arg list (so the compiler knows what is
templated but still figures out its own types).

Fixes #830

Apparently, starting with LLVM clang version 20, if you use the `template`
keyword to highlight a sub-element, you have to provide a template argument
list. This is true even for a method where the template arguments can be
completely determined by the types of the arguments. Fix this problem by
providing an empty template arg list (so the compiler knows what is
templated but still figures out its own types).

Fixes #830

`PointLocatorBase` used to use CRTP. However, this pattern is
unnecessary as the only real subclass it calls is Build, which does not
need templating. The base class does not have to call the
`PrepareForExecution` method, so it can provide its own features to
derived classes more easily.

Also moved `PointLocatorBase` out of the `internal` namespace. Although
it provides little benefit other than a base class, it will make
documenting its methods easier.

`CellLocatorBase` used to use CRTP. However, this pattern is unnecessary as
the only real subclass it calls is `Build`, which does not need templating.
The base class does not have to call the `PrepareForExecution` method, so
it can provide its own features to derived classes more easily.

Also moved `CellLocatorBase` out of the `internal` namespace. Although it
provides little benefit other than a base class, it will make documenting
its methods easier.

There was a use of a deprecated method buried in a support class of
`WorkletCellNeighborhood`. This fixes that deprecation and also adds a
missing test for `WorkletCellNeighborhood` to prevent such things in the
future.

The flying edges implementation has an optimization where it will traverse
meshes in the Y direction rather than the X direction on the GPU. It
created mostly correct results, but the triangles' winding was the opposite
from the CPU. This was mostly problematic when normals were generated from
the gradients. In this case, the gradient would point from the "back" of
the face, and that can cause shading problems with some renderers.

This has been fixed to make the windings consistent on the GPU with the CPU
and the gradients.

Fixes #825

The constructors for `vtkm::cont::Field` and `vtkm::cont::CoordinateSystem`
were missing from the built user's guide. The construction of these classes
from names, associations, and arrays are now provided in the documentation.

Also added new versions of `AddField` and `AddCoordinateSystem` to
`vtkm::cont::DataSet` that mimic the constructors. This adds some sytatic
sugar so you can just emplace the field instead of constructing and
passing.

The initial implementation of `CellInterpolate` takes arguments that are
expected from a topology map worklet. However, sometimes you want to
interplate cells that are queried from locators or otherwise come from a
`WholeCellSet` control signature argument.

A new form of `CellInterpolate` is added to handle this case.

In the previous guide, this was (mostly) in its own chapter. This may
have been an excessive amount of splitting things up.

There is still a missing section on the interface to the execution
environment (i.e. PrepareFor*). I plan to put that in the execution
objects chapter as this is the most likely place for a user to use them.

Some common VTK-m options such as the device and log level could be
specified on the command line but not through environment variables. It is
not always possible to set VTK-m command line options, so environment
variables are added.

Also added documentation to the user's guide about what options are
available and how to set them.

Several places in VTK-m use the `CastAndCallForTypesWithFallback` method in
`UnknownArrayHandle`. The method works well for catching both common and
corner cases. However, there was no way to know if the efficient direct
method or the (supposedly) less likely fallback of copying data to a float
array was used. VTK-m now adds a log event, registered at the "INFO" level,
whenever data is copied to a fallback float array. This helps developers
monitor the eficiency of their code.

VTK-m development is in a mode where backward compatibility should be
maintained between minor versions of the software. (You may get deprecation
warnings, but things should still work.) To match this behavior, the
generated CMake package now supports finding versions with the same major
release and the same or newer minor release. For example, if an external
program does this

``` cmake
find_package(VTKm 2.1 REQUIRED)
```

then CMake will link to 2.1 (of course) as well as newer minor releases
(e.g., 2.2, 2.3, etc.). It will not, however, match older versions (e.g.,
2.0, 1.9), nor will it match any version after the next major release
(e.g., 3.0).

There is a Thrust patch that works around an issue in Thrust 1.9.4
(https://github.com/NVIDIA/thrust/issues/972). The underlying issue
should be fixed in recent versions. In recent versions of CUDA, the patch
breaks (#818).

This change fixes the problem by disabling the patch where it is not
needed.

There was an issue where if VTK-m was compiled with CUDA support but then
run on a computer where no CUDA device was available, an inappropriate
exception was thrown (instead of just disabling the device). The
initialization code should now properly check for the existance of a CUDA
device.

The `ExtractGeometry` filter was outputing datasets containing
`CellSetPermutation` as the representation for the cells. Although this is
technically correct and a very fast implementation, it is essentially
useless. The problem is that any downstream processing will have to know
that the data has a `CellSetPermutation`. None do (because the permutation
can be on any other cell set type, which creates an explosion of possible
cell types).

Like was done with `Threshold` a while ago, this problem is fixed by deep
copying the result into a `CellSetExplicit`. This behavior is consistent
with VTK.

The Intel compiler by default turns on an optimization that assumes that
all floating point values are finite. This breaks any ligitimate uses of
non-finite values including checking values with functions like `isnan`
and `isinf`. Turn off this feature for the intel compiler.