I found those wrong types when trying to use a HarmonicEnergyStiffness
with a RigidBodyMotion.

Running the test aborts with an error, because the error is exactly
the same as before this patch.

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.

Introduce a dedicated class LocalQuickAndDirtyFEFunction to produce initial iterates for the GFE minimization problems

Previously, a LocalProjectedFEFunction was used for this.  This turned out to be a bad idea for two reasons:
- Evaluating such a function can actually pretty expensive.  For example,
  to project onto SO(3), the polar decomposition needs to be evaluated by
  an iterative method.
- Screwing up the LocalProjectedFEFunction implementation can actually screw up
  the GFE implementation as well in very subtle ways.  Specifically, if the
  LocalProjectedFEFunction is not ADOL-C-differentiable, then the GFE function
  will not be differentiable, either.  This fact cost me a few hours searching...

[cleanup] Move the FD approximation of the GFE function gradient from the GFE function into the test

It is a part of the test harness, and should not clutter the implementation of the
GFE functions themselves.

Patch by Jonathan Youett

[[Imported from SVN: r10056]]

It sometimes creates problems with ADOL-C.

[[Imported from SVN: r9841]]

Amazingly, this really does have a measurable effect on the overall computation
speed.  Assembly times for the global Hessian and gradient for the Cosserat shell
energy problem drop by about 5% (!)

[[Imported from SVN: r9837]]

[[Imported from SVN: r9813]]

This has two advantages:
- The two matrices use different number types (adouble vs. double),
  but the generic multiplication in dune/istl/matrix.hh doesn't support
  that.  Hence before this change I had to patch dune-istl.
- It avoids one extra copying operation

[[Imported from SVN: r9703]]

The new initial iterate is constructed by interpolating the values in Euclidean
space, and projecting back onto TargetSpace.  This has two advantages:
1) It's a better initial iterate, so we should converge faster than starting
   from coefficients_[0]
2) It makes it easier for ADOL-C to pick up correct second derivatives.
   Hence we are able to reduce the minimum number of iterations of the
   target space tr solver.

[[Imported from SVN: r9683]]

[[Imported from SVN: r9588]]

[[Imported from SVN: r9404]]

[[Imported from SVN: r9403]]

[[Imported from SVN: r9381]]

[[Imported from SVN: r9380]]

[[Imported from SVN: r9378]]

[[Imported from SVN: r9309]]

[[Imported from SVN: r9306]]

[[Imported from SVN: r9299]]

[[Imported from SVN: r9298]]

[[Imported from SVN: r9297]]

[[Imported from SVN: r8553]]

This change makes the localgeodesicfefunction test fail again.
So there must be a bug in the corresponding non-finite-difference
code.  Looking at simplex cases confirms me in this opinion.
But I don't find the bug...

[[Imported from SVN: r8463]]

[[Imported from SVN: r8462]]

[[Imported from SVN: r8376]]

To compute the derivative you need the function value (see my paper).
Therefore, it is computed as the first thing in the evaluateDerivative
method.  However, frequently, the assembler also needs the function value,
and also computes it.  Hence the function value is computed twice.
Since computing the function values takes quite a bit of time
this patch removes that redundancy, at the price of a slightly
more complicated API: if you happen to know the correct function
value when calling evaluateDerivative, you can now hand over the
value.  Then evaluateDerivative uses that value instead of recomputing it.

Short measurements have shown a speed increase between 25% and 45%.

[[Imported from SVN: r8362]]

[[Imported from SVN: r8182]]

target space classes.  In particular, the coordinate type
now has to be given explicitly.

[[Imported from SVN: r8149]]

[[Imported from SVN: r8059]]

[[Imported from SVN: r8051]]

[[Imported from SVN: r8045]]

add method to get the i'th base coefficient of a localGfeFunction and implement this method for the RigidBodyMotion template specialization

[[Imported from SVN: r8031]]

[[Imported from SVN: r8002]]

[[Imported from SVN: r7999]]

Compiles, but is not tested yet.

[[Imported from SVN: r7997]]

[[Imported from SVN: r7961]]

[[Imported from SVN: r7959]]