Co-authored-by: Vicente Bolea <vicente.bolea@kitware.com>
Co-authored-by: Chuck Atkins <chuck.atkins@kitware.com>

These were previously suppressed because they are unavoidable when
calling virtual methods. But we no longer support virtual methods on
devices (it is deprecated).

These warnings can still happen if you have unbounded recursion. But we
would like to avoid unbounded recursion, so we would like to see these
warnings.

Also turned on other nvlink warnings, which include when a recursive
function call means that the compiler cannot figure out the full
stack depth.

The new name is more descriptive and prevents confusion with
CellLocatorUniformGrid.

Code extracted from:

    https://gitlab.kitware.com/third-party/diy2.git

at commit f7a68da4fbe93ae7a8699b66f125a98ace842998 (for/vtk-m).

Any time there is a CUDA device class that has virtual methods,
nvlink will issue a warning if the resulting library is linked
into code that does not use that method, so we basically have
to suppress these warnings for any execution environment class
with virtual methods.

Now that we no longer use a recursive algorithm to find cells in a BIH
structure, the exception should no longer be necessary.

This will allow better suppression of cuda stack size warnings
for developers and build machines.

- Reducing the stack allocation for CUDA for the BIH unit test
- Adding changes from Ken's review
- Suppress ptxas stack size warning for BoundingIntervalHierarchy

Code extracted from:

    https://gitlab.kitware.com/third-party/taotuple.git

at commit ae4936580baf117373e73c23f0f8407d7589e6ff (for/vtk-m).

The PTX pass has pretty bad warning controls and we can't suppress
specific warnings for a single function. So instead we suppress
on dashboard the ptx warning for functions we know work

These parts are marked as TODO in DIY and hence we'll ignore these
warnings till DIY fixes those.

DIY code is rife with shadow warnings. Ignore those.

Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.

Porting the dax device adapter over to vtkm. Unlike the dax version, doesn't
use the thrust::device_vector, but instead uses thrust::system calls so that
we can support multiple thrust based backends.

Also this has Texture Memory support for input array handles. Some more work
will need to be done to ArrayHandle so that everything works when using an
ArrayHandle inplace with texture memory bindings.

These changes support the implementation of DispatcherBase. This class
provides the basic functionality for calling an Invoke method in the
control environment, transferring data to the execution environment,
scheduling threads in the execution environment, pulling data for each
calling of the worklet method, and actually calling the worklet.

The FunctionInterface class is a convienient way to wrap up a variable
number of arguments and pass them around templated interfaces without
requiring variadic template arguments. It also correctly hands return
arguments.

This includes the configure scripts to setup if you want a 32bit or
64bit build.