Add IdComponent and other base types with explicit widths

In preparation for supporting base types with more widths, add typedefs
for the base types with explicit widths (number of bits).

Also added a IdComponent type that should be used for indices for
components into tuples and vectors. There now should be no reason to use
"int" inside of VTK-m code (especially for indexing). This change cleans
up many of the int types that were used throughout.
Change vtkm::Tuple to vtkm::Vec

There are multiple reasons for this name change:

* The name Tuple conflicts with the boost::Tuple class, which as a
different interface and feature set. This gets confusing, especially
since VTK-m uses boost quite a bit.

* The use of this class is usually (although not always) as a
mathematical vector.

* The vtkm::Scalar and vtkm::Vector* classes are going to go away soon
to better support multiple base data type widths. Having this
abbriviated name will hopefully make the code a bit nicer when these
types have to be explicitly specified.

Also modified the implementation a bit to consolidate some of the code.
Change VectorTraits to VecTraits.

Matches the previous move from Tuple to Vec. We can unify on this name.
Allow longer base lists

Previously we just hand coded base lists up to 4 entries, which was fine
for what we were using it for. However, now that we want to support base
types of different sizes, we are going to need much longer lists.
Expand the list of types to include multiple widths.

Since we want our code to generally handle data of different precision
(for example either float or double) expand the types in our list types
to include multiple precision.
Change tests that try all base types to use different precision

Before we assumed that we would only use the basic types specified by
the widths of vtkm::Scalar and vtkm::Id. We want to expand this to make
sure the code works on whatever data precision we need.
Remove vtkm::Scalar and vtkm::Vector# types

Providing these types tends to "lock in" the precision of the algorithms
used in VTK-m. Since we are using templating anyway, our templates
should be generic enough to handle difference precision in the data.
Usually the appropriate type can be determined by the data provided. In
the case where there is no hint on the precision of data to use (for
example, in the code that provides coordinates for uniform data), there
is a vtkm::FloatDefault.
TypeListTagAll should really have all basic types.

The previous commits had TypeListTagAll containing a subset of Vec
types. This commit adds all possible vectors with 2 to 4 components
containing one of the basic C types.
Merge branch 'any-scalar-width'
Rename some type lists to be a bit more consistent.
Merge branch 'any-scalar-width'
Unify test values.

Lots of tests have to move values in and out of arrays and check them
against expected values. It is also often the case that these tests are
run on lots of different types. There is some repeated code for
generating known values for particular indices. This change unifies some
of that. This can probably also encourage making more generic tests.
Merge branch 'unify-test-value'
Add Transport class

The Transport class is responsible for moving data from the control
environment to the execution environment. (Actually, it might be more
accurate to say it gets the execution environment associated with a
given control object.) The Transport class is templated with a tag that
controls the mechanism used for the transport.
Add Fetch class

The Fetch class is responsible for moving data in and out of some
collection in the execution environment. The Fetch class is templated
with a pair of tags (the type of fetch and the aspect) that control the
mechanism used for the fetch.
Add basic worklet superclasses and signature tags
Add ability to zip function interface objects.

The zip capability allows you to parameter-wise combine two
FunctionInterface objects. The result is another FunctionInterface with
each parameter a Pair containing the respective values of the two
inputs.

Being able to zip allows you to do transforms and invokes on data that
is divided among multiple function interface objects.
Add basic dispatcher functionality.

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.
Add DispatcherMapField.

This is a simple version of a dispatcher, but an important one.

Note that there is an issue brought up with UnitTestWorkletMapField in
that there needs to be better ways to specify worklet argument types.
Fix MSVC compiler warnings

Generally, the MSVC compiler tends to be more picky about implicit type
conversions. It warns if there is any possibility of precision loss.