In theory this is dangerous, because a pure Newton method will
only converge locally.  However, the trust-region part had been
partially disabled anyway, and I have not noticed any problems.
Also, I think that from my well-posedness result for higher-order
GeoFEs follows that a Newton method will always converge if the
problem is well-posed (that is how the proof works, after all).

On the plus side, this patch brings roughly 5% speed increas.

Assuming that the AverageDistanceAssembler can provide it.

This is for the Gram-Schmidt solver only.  The old Gauss-Seidel
code will still use a full matrix.

[[Imported from SVN: r9585]]

CG seems to converge to quickly.  If too few iterations are performed,
then ADOL-C has trouble determining the correct second derivatives.
Since the Gram-Schmidt solver is a direct solver, OTOH, the derivatives
should be perfect.  It is also faster than the Gauss-Seidel solver I
was previously using.

[[Imported from SVN: r9581]]

I hoped that this would be faster.  However, it seems to deterioate the
convergence of the outer trust region algorithm.  Apparently, the steps
taken by a CG make it difficult for ADOL-C to compute the correct
derivatives.

[[Imported from SVN: r9576]]

[[Imported from SVN: r9476]]

[[Imported from SVN: r9450]]

[[Imported from SVN: r9304]]

[[Imported from SVN: r9303]]

[[Imported from SVN: r7838]]

[[Imported from SVN: r7611]]

[[Imported from SVN: r7576]]

and barycentric coordinates.  This is easy because we know the
number of element corners at compile time (I currently don't
see support for non-simplex elements at all).  This saves 
time, but not much: about 1%.

[[Imported from SVN: r7550]]

[[Imported from SVN: r7549]]

[[Imported from SVN: r7229]]

... instead of coordinates in the embedding space.  The usual problem
is that when working in the embedding space, a projection onto the
trust-region makes the iterate leave the tangent space.

[[Imported from SVN: r7035]]

[[Imported from SVN: r6673]]

For this now the TangentVector class of S^n has only n components,
while the EmbeddedTangentVector class still has n+1.
The code around it needs to be fixed accordingly.

[[Imported from SVN: r5963]]

[[Imported from SVN: r5931]]

[[Imported from SVN: r5548]]

[[Imported from SVN: r5534]]

[[Imported from SVN: r5528]]

[[Imported from SVN: r5347]]

[[Imported from SVN: r4138]]