The multigrid hierarchy is built in two different ways, depending on whether
we use a P1NodalBasis for the discretization, or anything else.  Previously,
this switch was made using the preprocessor.  The patches changes the code
to use std::is_same instead.

[[Imported from SVN: r10046]]

This is much cleaner than handing over the Grid only, and then trying
to guess the basis using the preprocessor.  After all, the
RiemannianTrustRegionSolver calls the assembler, so it may know the
function space basis.

[[Imported from SVN: r10035]]

By introducing a factory class that produces GlobalMapper and LocalMapper
types for a given dune-fufem-style function space basis.

[[Imported from SVN: r10034]]

[[Imported from SVN: r10033]]

[[Imported from SVN: r10032]]

[[Imported from SVN: r10031]]

... while keeping compatible with dune 2.3

[[Imported from SVN: r10030]]

This implements a global GFE function (inheriting from VirtualGridViewFunction).
However, the return value of this function is _not_ a manifold class.  Rather,
the manifold is embedded into a Euclidean space.  Hence this class is formally
simply vector valued, and can be used in error measurement routines and such.

[[Imported from SVN: r10024]]

[[Imported from SVN: r10014]]

... so much difficult code obsolete now... AD rocks...

[[Imported from SVN: r10010]]

[[Imported from SVN: r9997]]

Described in:
 Christof Melcher, "Chiral skyrmions in the plane", Proc. of the Royal Society, online DOI DOI: 10.1098/rspa.2014.0394

[[Imported from SVN: r9996]]

[[Imported from SVN: r9995]]

[[Imported from SVN: r9994]]

    
This removes a compiler deprecation warning.  By using the usual preprocessor magic
we retain compatibility with the dune 2.3 release.

[[Imported from SVN: r9993]]

There is no need to have our own implementation for this, we had it purely for
historical reasons.

Also, this change fixes a subtle bug:  Our own implementation used AlienElementLocalBasis,
which returns zero if the LocalBasis is evaluated outside of the reference element.
However, this happened sometimes due to rounding error on grids with very small quadrilateral
elements.

[[Imported from SVN: r9991]]

[[Imported from SVN: r9990]]

[[Imported from SVN: r9980]]

[[Imported from SVN: r9979]]

[[Imported from SVN: r9978]]

[[Imported from SVN: r9977]]

This already saves a lot of disk space, because the class issues less whitespace
than our own code.  Plus, switching to binary data will be very easy now.

[[Imported from SVN: r9976]]

[[Imported from SVN: r9975]]

[[Imported from SVN: r9973]]

[[Imported from SVN: r9972]]

[[Imported from SVN: r9971]]

[[Imported from SVN: r9967]]

[[Imported from SVN: r9966]]

[[Imported from SVN: r9965]]

Previously, the number of multigrid transfer operators was always equal to
the number of grid levels minus one.  That worked out correctly when doing
first-order FE spaces.  However, for higher-order spaces, the up-most transfer
operator transfers from the higher-order space to a first-order space
_on the same grid level_.  But since the total number of transfer operators
was grid levels minus one, this implied that the coarsest grid leve 
was never used, and the coarse grid solver would operate on the second-coarsest
grid.

This patch adds the extra transfer operator in this case.  That means we now
call the coarse grid solver on smaller problems, which makes a noticeable
run-time difference.

[[Imported from SVN: r9964]]

[[Imported from SVN: r9963]]

Normally, the two different level grid views.  Previously we used the same one
to compute the localToGlobal renumbering for boths rows and columns.  Of course
that screws up the numbering.

I am not quite sure when that got introduced.  I may have gotten in fairly recently,
after the upstreaming of the GlobalIndexSet classs.

[[Imported from SVN: r9962]]

[[Imported from SVN: r9961]]

[[Imported from SVN: r9960]]

[[Imported from SVN: r9959]]

May happen when the matrix is singular.  UMFPack doesn't like that.

[[Imported from SVN: r9958]]

It tentatively uses the UMFPack direct solver, disregarding the obstacle.
If that leads to an energy-decreasing, admissible new iterate, then good.
Otherwise, it falls back to IPOpt.

[[Imported from SVN: r9957]]

[[Imported from SVN: r9956]]

[[Imported from SVN: r9955]]

[[Imported from SVN: r9954]]