Previously, this test used a situation with geodesic interpolation
between two points on the sphere that are almost antipodal.
This made the TargetSpaceRiemannianTRSolver crash, because the
weighted sum of squared distances can have indefinite second
derivatives in such a situation.  In principle, the
TargetSpaceRiemannianTRSolver should handle this, but nowadays
it is not actually a TR solver anymore, but a plain local
Newton method.  Maybe I should revert back to trust-region.

I added a comment to targetspacetrsolver.cc that explains the
situation a little.

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.

With the better initial iterate introduced in the previous patch,
this lower number seems to be sufficient.

[[Imported from SVN: r9684]]

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

[[Imported from SVN: r9582]]

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: r9563]]

[[Imported from SVN: r9476]]

[[Imported from SVN: r9450]]

[[Imported from SVN: r9304]]

[[Imported from SVN: r9303]]

[[Imported from SVN: r8861]]

[[Imported from SVN: r7838]]

[[Imported from SVN: r7611]]

notably the almost-equivalent UnitVector<4>: A vector with three entries
is interpreted by the UnitVector<4> class as a tangent vector given in
the basis returned by orthonormalFrame.  That is correct as it works
for all kinds of manifolds.  On the other hand, the Rotation<3> class
interprets as a 3x3 skew matrix (a tangent vector at the identity in
the matrix representation) even though the implementation used quaternion
coordinates.

To trick around this the use of exp methods with FieldVector<3> is avoided
by this patch.  A real fix would involve introducing a SkewMatrix class
and using that in Rotation<3>.

[[Imported from SVN: r7575]]

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: r7350]]

[[Imported from SVN: r7229]]

[[Imported from SVN: r7172]]

[[Imported from SVN: r5931]]

[[Imported from SVN: r5794]]

[[Imported from SVN: r5595]]

[[Imported from SVN: r5587]]

[[Imported from SVN: r5572]]

[[Imported from SVN: r5548]]

[[Imported from SVN: r5541]]

[[Imported from SVN: r5540]]

[[Imported from SVN: r5535]]

[[Imported from SVN: r5528]]

[[Imported from SVN: r5510]]

[[Imported from SVN: r5347]]

[[Imported from SVN: r4470]]

[[Imported from SVN: r4138]]