It is not important for this test, but we might as well make the
compiler happy.

We aren't modifying the value, so no reason to not have it as const.

The ExecObject tag for the ControlSignature was not declared right so
would cause a compile error if it was ever used. Clearly this was not
being tested properly, so the dispatcher base unit test now passes an
ExecObject parameter.

THe IncrementBy2 test type previously allowed any subtype including
floating point numbers. The meaning of this is actually a little unclear
and the feature was causing implicit type conversion warnings that were
hard to template out. The utility of of templating this class is dubious
in the first place, so class is now a fixed type.

I'm a little unsure whether we should keep this test class at all. It's
math operations are ad hoc and it could be difficult to determine if a
problem is caused by an actual problem or just bad math operators.

MSVC complains that converting a 32-bit int to a 32-bit float could
cause loss of precision.

Fix compile warnings that come up with the flags

  -Wconversion -Wno-sign-conversion

This catches several instances (mostly in the testing framework) where
types are implicitly converted. I expect these changes to fix some of
the warnings we are seeing in MSVC.

I was going to add these flags to the list of extra warning flags, but
unfortunately the Thrust library has several warnings of these types,
and I don't know a good way to turn on the warnings for our code but
turn them off for Thrust.

The UnitTestArrayHandlePermutation test was failing when compiled with
icc. I believe the issue is that the icc optimization takes some
liberties when computing literal floating point values versus computing
them at run time that makes the two slightly different. I changed all
the applicable comparisons in this test from using the == operator to
using the test_equal function, which adds a tolerance to the comparison.
I expect this to fix the test failure.

There are often instances where one wants to make an assert check in a
method that can run in either the control or execution environment. This
is rather difficult in general for the execution environment, but with
this change you can place the VTKM_ASSERT_CONT macro in such a method,
and it should compile even under CUDA. It works by removing the macro if
compiling for a CUDA device.

By default visual studio limits the number of sections in an object file
to 2^16 which isn't enough when creating some of our tests. So we enable
/bigobj which increases that number to 2^32.

Using NOMINMAX and WIN32_LEAN_AND_MEAN allows us to reduce the number
of macro's and functions we bring in from windows.

Fancy array handles being Counting, Implicit, Permutation, Transform, and Zip.

Allows both reading and writing to a vtkm::pair of values.

Previously, DispatcherBase had an ivar to determine whether to use the
numInstances passed on the stack or to use a 3D range held in a
different ivar. This change allows either a 1D range or 3D range to be
passed on the stack, which I expect to be closer to how we we handle
this when 3D ranges are fully supported.

This also fixes a bug introduced with commit
fdac208a where the Use3DSchedule ivar
was not set correctly in UnitTestDispatcherBase.

In retrospect, I probably should have called this branch fancy-array-handles,
but it's not that much different.