Also cleaned up some lingering type typedefs.

Since Field association is used either when creating or working
with 'vtkm::cont::Field', it's put in the class itself.

This commit also removes the old static_cast<vtkm::float32>vtkm::Pi() usages and
fix serveral conversion warnings.

This keeps the old name around but prepares it for removal
in the next release.

- Use tao::tuple instead of FunctionInterface to hold array/portal
  collections.
- Type signatures are simplified. Now just use:
  - ArrayHandleCompositeVector<ArrayT1, ArrayT2, ...>
  - make_ArrayHandleCompositeVector(array1, array2, ...)
  instead of relying on helper structs to determine types.
- No longer support component selection from an input array. All
  input arrays must have the same ValueType (See ArrayHandleSwizzle
  and ArrayHandleExtractComponent as the replacements for these
  usecases.

The id4 while always valid is constructed using a lookup table and the
compiler can't see if that will always be a valid vec 4.

Prevously, the x field of view was computed by scaling the y field of
view by the aspect ratio of the canvas. However, this is wrong because
the field of view angles do not scale linearly with the aspect ratio.
Fix this issue by using trig functions to convert the angle to distance,
scale the distance, and then convert back to angle.

The raytracing code has its own version of camera that maintains two
field of view (fov) parameters: one for the x direction and one for the
y. The standard vtkm::rendering::Camera contains only one fov. As is
consistent with OpenGL's gluPerspective and VTK's camera, the fov is
specified in the y direction. However, the raytracing code was
incorrectly using it in the x direction. That caused it to do a weird
rescaling when the aspect ratio was not 1.

The new and improved vtkm::cont::ColorTable provides a more feature complete
color table implementation that is modeled after
vtkDiscretizableColorTransferFunction. This class therefore supports different
color spaces ( rgb, lab, hsv, diverging ) and supports execution across all
device adapters.

These changes now allow VTK-m to compile on CUDA 7.5 by using const arrays,
when compiling with CUDA 8+ support we upgrade to static const arrays, and
lastly when CUDA is disabled we fully elevate to static constexpr.

Found via `codespell -q 3`

these need a little  more review. 

Found via `codespell -q 3` via downstream VTK

Makes the interface compatible with DynamicArrayHandle.

Visual Studio default toolset uses 32bit executables for compiling which
means that if it uses more than 4GB of memory per instance it crashes.
By moving the ConnectivityTracer into a separate compilation unit we
can help out the compiler.

This also improved compilation times and library size:

Old:
build time (j8): 48.62 real
lib size: 6.2MB

New:
build time (j8): 41.31 real
lib size: 5.0MB

If a global static array is declared with VTKM_EXEC_CONSTANT and the code
is compiled by nvcc (for multibackend code) then the array is only accesible
on the GPU. If for some reason a worklet fails on the cuda backend and it is
re-executed on any of the CPU backends, it will continue to fail.

We couldn't find a simple way to declare the array once and have it available
on both CPU and GPU. The approach we are using here is to declare the arrays
as static inside some "Get" function which is marked as VTKM_EXEC_CONT.

adding 2d ortho support to ray tracing and updating WireFramer to support 2d lines and 1D line plots

Fixes a linker error about not finding 'LinearBVH::ConstructOnDevice'

This will make VTK-m warning level match the one used by VTK. This commit
also resolves the first round of warnings that W4 exposes.

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.