Previously, the following piece of code would compile and only
only predictable fail at runtime with assertions enabled.

  Dune::FieldMatrix<double, 2, 3> A;
  // populate A

  Dune::FieldMatrix<double, 3, 2> B_bad;
  // populate B_bad
  A.rightmultiply(B_bad);

It now fails to compile.

Previously, the following piece of code would compile but then enter a
loop, typically leading to a segmentation fault

  Dune::FieldMatrix<double, 2, 3> A;
  // populate A

  Dune::DynamicMatrix<double> B_good(3, 3);
  // populate B_good
  A.rightmultiply(B_good);

This would also happen for the following illegal extension of the above code

  Dune::FieldMatrix<double, 3, 2> B_bad;
  // populate B_bad
  A.rightmultiply(B_bad);

The former now works as expected while the latter fails an assertion.

The standard leaves (the effect of instantiating) complex<T> for more
general T unspecified.

While we're at it, kill duplicate tests and add long double to the list

This also adds two test utilities from dune-functions
that are both used in this test.

* TestSuite: A helper class to organize checks in tests
  in a unified way and more readable way.
* CollectorStream: A simple stream that allows to collect
  data and forward it to its creator using a callback.
  Used by testsuite.hh

Since can also be used for tests in other modules they
are installed in dune/common/test. However, CollectorStream
is not strictly related to tests and may also be moved directly
to dune/common/.

This removed the recently added prioritytag.hh
header again. Having a separate header for each
of these trivial helpers will only clutter the
directory and make people lookup the correct
header more often.

This header should be used to collect all utilities for
type computations, constraining overloads, and similar
purposes, that are not type-traits.

The main feature of this header is the constexpr function
models(). The result of

  models<C, T1, ..., TN>()

indicated if the concept C is modeled by the collection
(T1, ..., TN) of types. A concept is a list of valid
expressions that a type must support. Concepts can refine
other concepts to inherit all requirements from those
base concepts.

Besides the concept check function itself, the header contains
some helper functions of the form require requireFoo for additional
checks. The purpose of those functions is to transform a non-satisfied
condition Foo to a substitution failure, such that the corresponding
expression is not valid. E.g.,

  requireConvertible<R>(t.f())

is not valid unless the result of t.f() is convertible to R.

We should always export ::Type and ::type to follow
the dune convention and the std pattern for type traits.

This can be used to 'store' an argument pack and access
its members. In contrast to a std::tuple<T...> which is
a container of objects of types T... a TypeList<T...>
only captures the types T... . Hence one can easily
create TypeList objects and use them to pass types around
or. e.g., in overload resolution where they can be used for
tag-dispatch.

This class is e.g. used in the concept checking facility
I'll add soon.

Notice that adding a template packer<T...> doing exactly
the same has been proposed for the standard in N4115

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4115.html

This is intended to contain everything related to type
computations, like, e.g., type traits, helpers for
overload resolution, ...

The alignof() operator was introduced in C++11.