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.

This is technically not necessary, but hides about 5 MB of compiler
warnings :-D