Rework ReferenceElement interface

This merge request switches the reference elements to value semantics and adds a freestanding function referenceElement() to get reference elements for arbitrary objects supporting the operation.

This whole thing started as the dune-geometry side of implementing dune-grid#65 (closed), but ballooned just a little ;-). As pointed out in that issue, having this type of function will also allow for reference elements that are not provided as singletons, so we really need value semantics for the returned object. At the same time, these transitions from const ref to value have bitten us in the past with hard-to-find errors, so we should try and have a clean transition with deprecation warnings for the user. That's what this merge request tries to do.

From the user's point of view, it introduces the following changes:

• Reference elements and the container Dune::ReferenceElements<ctype,dim> now export the coordinate field type, the coordinate type and the dimension. The container also exports the type of the reference element as a nested type ReferenceElement.
• Reference elements now have value semantics and should be captured by value, copied around etc.
• As they have value semantics, everything returned by a reference element now also has value semantics.
• If you try to assign a reference element to const Dune::ReferenceElement<ctype,dim>&, you get a deprecation warning.
• There is now a set of freestanding functions referenceElement(...) that allow for the following calls (note that in general, the function will be found using ADL, but in the first two of the following variants, that doesn't work due to the explicit template arguments):
  • auto ref_el = Dune::referenceElement<ctype,dim>(geometryType);
  • auto ref_el = Dune::referenceElement<ctype>(geometryType,Dune::Dim<dim>());
  • auto ref_el = referenceElement(ctype(),geometryType,Dune::Dim<dim>());
• With corresponding changes in dune-grid, you can also get the reference element for a geometry by calling referenceElement(geometry).
• Dune::ReferenceElement<T...> will become a meta function to obtain the return type of the corresponding call to referenceElement(t...). In DUNE 2.6, this only works for a single argument, as we have to maintain backwards compatibility to the old signature Dune::ReferenceElement<ctype,dim>.
• Any usage of Dune::ReferenceElement<ctype,dim> is flagged as deprecated in DUNE 2.6.
• The multi-argument version of Dune::ReferenceElement<T...> is available as Dune::Transitional::ReferenceElement<T...> in DUNE 2.6. This version will move to the main Dune namespace for the next release after 2.6.

As a consequence of the changed semantics of Dune::ReferenceElement, the merge request moves all of the reference element implementation and the new value-based interface class to the nested namespace Dune::Geo, as Dune::Geometry is blocked by the interface class in dune-grid. Interestingly, I noticed that there were already freestanding functions referenceElement(geo) for the geometry implementations in dune-geomtry, but not for the interface class in dune-grid. As these functions returned const ReferenceElement&, I changed them to return by value.

The new interface class Dune::Geo::ReferenceElement<Impl> works like a simple handle class and just stores a raw const pointer to an implementation object that it assumes to be a singleton for the purposes of equality comparisons. It should also work for other simple singleton implementations. The old reference element class was renamed to Dune::Geo::ReferenceElementImplementation and is now considered an implementation detail (it also doesn't show up in Doxygen anymore). The deprecation mechanism relies on a derived helper class of the new interface and can be easily removed by reverting a single commit, although Dune::ReferenceElement will require some additional work.

The merge request also adapts (hopefully) all of dune-geometry to the new semantics and interfaces, but most of the changes will have to happen in downstream modules