Commented out checking for head and tail of warpList, as they don't contain values, they're just marks to the end of the list.

Preliminary templating of WarpInfo and WarpList. Preliminary fix of mistake where WarpList would loop infinitely. Added checkpoints. Committing for backup purposes.

addWarp( const int, const int, const int, const int * ) takes int, but
in balanceLoad is given IndexType!! recast or rewrite warp list/info
using IndexType?

Closes #49

They are not suitable for more than 2 devices/execution types; their design
breaks the Open-Closed Principle. Instead, a type template "Self" was
created, which allows to change any template parameter.

The usage of algorithms such as MemoryOperations or Reduction is not
bound to a particular container. On the other hand, ArrayIO,
ArrayAssignment, VectorAssignment and StaticArrayAssignment are just
implementation details for the containers - moved into
TNL/Containers/detail/

Also moved ParallelFor, StaticFor, StaticVectorFor, TemplateStaticFor
into TNL/Algorithms/

This will be necessary to avoid code bloat with more than 2 devices
(execution types).

Moved synchronization of smart pointers from Devices::Cuda into TNL::Pointers namespace as free functions

synchronizeDevice() was renamed to synchronizeSmartPointersOnDevice()
for clarity - there are many similarly named functions in CUDA (e.g.
cudaDeviceSynchronize()).

Moved (most of) static methods from TNL::Devices::Cuda as free functions into separate namespace TNL::Cuda

The class TNL::Devices::Cuda was too bloated, breaking the Single
Responsibility Principle. It should be used only for template
specializations and other things common to all devices.

The functions in MemoryHelpers.h are deprecated, smart pointers should
be used instead.

The functions in LaunchHelpers.h are temporary, more refactoring is
needed with respect to execution policies and custom launch parameters.

Fixes #46

getConstView should be always used for const operations, because
explicit is better than implicit. Overloading one method for cases which
have a completely different type (ConstViewType is *not* just a
const-qualified ViewType) can be very unclear (or even ambiguous) in
certain cases.