This compiler gets tripped up parsing tao's zip implementation.

This fix addresses issue #110. Test functions in TestingDeviceAdapter have
been updated to test large arrays through random indices using
std::uniform_int_distribution rather than testing every 100th or 50th value.

There was a direct edit to WorkletInvokeFunctorDetail.h that was not
reflected in WorkletInvokeFunctorDetail.h.in. This makes the two files
consistent so that future edits will not loose the changes.

Compilation error (C2666) is caused by ambiguous call to overloaded function
vtkm::io::writer::VTKDataSetWriter::WriteDataSet().
One of the overloaded functions was not constant (though it is supposed to be).
This fixes compilation error in example "ParticleAdvection" when building
in Windows 7 Visual Studio 2015.

Also cleaned up some lingering type typedefs.

The nvcc-vtable-order-depends-on-per-translation-unit-instantiation-order
bug was to blame.

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 way we only install thirdparty headers and CMake information
when VTKm_INSTALL_ONLY_LIBRARIES is set to false.

gradient scalar output now has a prepare for execution function for creating the execution object based on the device adaptor.

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

This commit adds a worklet and a filter to compute
signed integral measures of cells.

It also begins the practic of adding a markdown
changelog entry in `doc/changelog`. See the
changelog entry for details.

When copying small arrays from cpu memory to pascal memory we would
see subsequent kernels fail as the memory transfer hadn't finished.
This is a bug as each stream should act like a FIFO queue. So
for now when encountering this use case we explicitly synchronize
after the memcpy.

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

Since we now use a CUDA-aware tuple object to store ArrayHandles and
Portals for the CompositeVector, these must be constructable on
devices.

This means that we not only setup the runtime device tracker
to force the intended device, it also means making sure
the default device is the error device.

These cause warnings with the nvcc compiler

- Missed a ',' to seperate template argument in GridEvaluator
- Adding initialization of params to Integrators for RK4
- Fixing ExecutionBaseObject changes for Particles

Adding Utkarsh's changes from 86bd81de to Rectilinear grid as well
 - To make rectilinear grids work with any storage type

Adding Rob's changes from 7d6fe568 to the RK4Integrator
 - Previously the RK4Integrator could compute velocity with uninitialized inputs.

Adding Rob's changes from a6bf830f to ParticleAdvection
 - Previous ParticleAdvection would dispatch some of the worklets on the default device adapter
   and not the explicitly requested device adapter

Adding Ken's change from 0753131a
 - For supporting all the previous merge conflicts with the new ExecutionObjectBase change.

If they are used inside other mathematical expressions then the compiler
has a better chance to perform the operation at compile time.

The previous implementation of DeviceAdapterRuntimeDetector caused
multiple differing definitions of the same class to exist and
was causing the runtime device tracker to report CUDA as disabled
when it actually was enabled.

The ODR was caused by having a default implementation for
DeviceAdapterRuntimeDetector and a specific specialization for
CUDA. If a library had both CUDA and C++ sources it would pick up
both implementations and would have undefined behavior. In general
it would think the CUDA backend was disabled.

To avoid this kind of situation in the future I have reworked VTK-m
so that each device adapter must implement DeviceAdapterRuntimeDetector
for that device.

The per device tests specifically setup the default backend to
be error to smoke out bad uses of the default backend.

While making changes to how execution objects work, we had agreed to
name the base object ExecutionObjectBase instead of its original name of
ExecutionObjectFactoryBase. Somehow that change did not make it through.

This is done to not only reduce the amount of code that users need
to generate but to reduce the amount of errors when using
the RuntimeDeviceTracker. If the runtime device tracker is initially
used in a library by a c++ file it will never properly detect the
cuda backend. By moving the code into vtkm_cont we can make sure
this problem doesn't occur.

These warnings were detected on my local machine.

Suppresses "declared but never referenced" warnings.