All dynamically allocated objects in the smart pointers were aggregated
into a single structure to avoid the number of dynamic allocations,
decrease the size of the smart pointer classes and to make the code more
readable.

This reverts commit 40379dcf.

This will indicate to the user that the data will not be modified in the
solver. I think that it's not necessary to differentiate between e.g.
MatrixPointer and MatrixConstPointer, because these are implicitly
mutually assignable.

This might happen e.g. if lazy is true and synchronize() is called before the
objects are created,

SharedPointer and UniquePointer: combined 'pointer' and 'last_sync_state' into an array to avoid one allocation

Also added the allocate method to DevicePointer and UniquePointer for
consistency. Added missing free() method to UniquePointer.

- base class with non-virtual destructor causes undefined behaviour
- missing return statements at the end of non-void functions
- missing const before char* function argument
- reordered initialization of class members
- misleading indentation after for statement
- fixed use of uninitialized variables
- fixed unsequenced modification and access to variables (the C++
  standard does not define the evaluation order of operands, so
  expressions with side-effects such as j++ cause undefined behaviour)

Plus the associated revamping of the SolverStarter. Also
ODESolverMonitor has been removed as its functionality has been merged
into the IterativeSolverMonitor.

Apart from squashing begin, end, entityOrientation and entityBasis
parameters into TraverserKernelData, this does not improve performance
of the LinearSystemAssembler, ExplicitUpdater etc., but in tnl-mhfem it
allows us to pass MeshDependentData, which is already available as a
SharedPointer, directly to the grid traverser without duplicating the
transfer to GPU.

The original 'modified' flag was not shared between instances of the
smart pointer, so theoretically the same data object might have been
synchronized more than once or even not at all.

Another problem with the detection was that e.g. access through the
modifyData method does not imply modification of the object's class
data. For example if the object is TNL::Vector, we need to go through
modifyData to be able to modify the vector data, but synchronization is
not needed since we go through another pointer. Another example is
repeated binding of the same object, e.g. bindDofs in the Problem
classes.

This is for consistency and also to avoid compiler warnings

This is necessary if the pointer type is const-qualified.

This can handle non-const -> const constructions and assignments. Due to
the automatically generated copy- and move-constructors and assignment
operators, some SFINAE tricks and little code duplication are needed to
make it work.

The compiler itself takes care of the problem by doing the right thing
in the problematic methods and not allowing to modify the
const-qualified data.