[[Imported from SVN: r9989]]

[[Imported from SVN: r9988]]

[[Imported from SVN: r9987]]

[[Imported from SVN: r9986]]

[[Imported from SVN: r9985]]

[[Imported from SVN: r9984]]

[[Imported from SVN: r9983]]

[[Imported from SVN: r9982]]

[[Imported from SVN: r9981]]

[[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: r9974]]

[[Imported from SVN: r9973]]

[[Imported from SVN: r9972]]

[[Imported from SVN: r9971]]

[[Imported from SVN: r9970]]

[[Imported from SVN: r9969]]

[[Imported from SVN: r9968]]

[[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]]

Because it is not an index, it really is a mapper.

[[Imported from SVN: r9953]]

[[Imported from SVN: r9952]]

[[Imported from SVN: r9951]]

This is a first step towards having trust-regions with different scaling
in the different components.  Kinda paradox to introduce an explicit radius
in order to move away from a single radius.  But I want to pretend to
the outside (for the time being) that there is a single radius...

[[Imported from SVN: r9950]]