Make FieldTraits less greedy

The idea of the FieldTraits class is to provide the field_type and real_type of various types representing numbers, vectors, ... . So far there was a default implementation

template<class T>
struct FieldTraits
{
  typedef T field_type;
  typedef T real_type;
};

This does not make much sense, for types that do not represent numbers. The patch ensures that the default implementation does only provide the typedefs if Dune::IsNumber<T> is true and that it is empty otherwise.

This also fixes a seemingly unrelated issue: If you defined operator*(T,T) and dot(T,T) for your own type (or concept) T, then dot is ambiguous, because there's a very greedy implementation in dotproduct.hh.

Here is a list (thanks to @simon.praetorius for the collection...) of wrong usage/missing specializations which must be fixed before merging:

• dune-istl: dune/istl/multitypeblockvector.hh:80 if no types are given or there is no common field-type of all the components, set as field_type the fallback Dune::Std::nonesuch. This results in an error, but occurs in recursive implementations because the fallback field_type is used to define a real_type. This is not correct and a corresponding nonsuch should also be defined as real_type instead. (dune-istl!480 (merged))
• dune-localfunctions: dune/istl/multiindex.hh: a type parametrized with Field type. This should be the definition in FieldTraits (dune-localfunctions!217 (merged))
• dune-localfunctions: dune/istl/tensor.hh: The LFETensor is a container type, thus should recursively define the FieldTraits. Also, there is the class Derivative defining also a field type. (dune-localfunctions!217 (merged))
• dune-common: dune/common/debugalign.hh: Need specialization for IsNumber for AlignedNumber
• dune-common: SimdArray is not detected as a valid field type anymore.
• dune-common: dune/common/fvector.hh:323: Constructor leads to second order substitution failures and thus a compile error when compiling dune-spgrid tests
• dune-istl: Also the Dune::FieldTraits<Vc_1::SimdArray<...>> needs a specialization.