Now that Type is the actual return type, it cannot be abstract
such that we can use the function signature notation again which
also allows to have a default value for the Key type.

This is only a conveneince method. The same can be achived
using a proper lambda as creator function. I'm not sure if
we really want this method. Because it does require to
ignore the arguments passed to the create() method which
seems to be a nasty hack.

This allow to also use types with a non-compatible constructor
if a proper creator function is provided.

Explicitly select unique_ptr or shared_ptr

With this change one has to explicitly select unique_ptr and shared_ptr.
This allows to also use the factory with types having value semantics.
The result type could be, e.g. std::function<...> and the implementation
types would need to have a proper signature.

This does not compile with gcc-4.9 and is probably invalid.

This commit also removes the redundant implamentation class *Base.

This allows to give priorities to otherwise ambiguous
overloads. It's main use is to make multiple overloads
work, when only some are ruled out via SFINAE. This is
e.g. used in the concepts check that I'll move to
dune-common soon.

The implemention is trivial but makes such applications
more readable and idiomatic compared to other approaches
where, e.g., null pointers are passed to overloads
have T* and void* dummy arguments.

Due to it's simplicity a separate header may not be justified,
but none of the existing seems to fit.

we use all argument types as they are. This requires us to specify any references, 
const qualifies, etc. explicitly, but it allows us to fully specify the interface.

the documentation already states that not brackets mean default ocnstructor, which might be 
the better idea. Let's discuss this.

we want to allow for constructor signatures with no, one or multiple parameters. 
The test now checks these different setups.

Further we allow for a default parameter. Currently this is Dune::ParameterTree,
but I'm not sure, whether this is a good idea or not.

The warning was added before FS#493 and the related FS#491
were resolved. Probably it was just forgotten to remove the
warning.
I double checked with GCC 5 and -O3. Works for me.

Probably an error caused during merging.

Nothing needs to be included with proper C++11 compilers.

Old feature support macros which were tested until 2.4, kept around
for one more release. As these are now always supported due to the
new compiler requirements, they are directly defined without an
explicit test.

As documented, tranformTuple should support AddRefTypeEvaluator. As
std::make_tuple will remove references (using std::decay) from the
funtor's return type, the returned tuple would contain copies of the
values. This is not the intended behavior.

This patch adds AddRefTypeEvaluator to the utilitytest and fixes the
return type of transformTuple.

These commits broke compiling / linking if one package was found
but the includes / libraries were not added. We need a different
approach to hide the ENABLE_* trick from the user and keep full
testing capabilities.
This reverts commits 0f12caff
and d75c3a46.

This reverts commit 4441ec26.
The minimal required is finally GCC 4.7 or newer (it is actuall 4.9).
Original commit message for d26e5ed3 was
    [C++11] Follow the C++11 specification of operator new.

    The signature changed in C++11 which we require now.
    To get more details see the mailinglost in October 2012.