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.