Previously we returned a sum of 0 when the length is 1, when really
we need to return the value that is in side the single location of the
array.

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.