Feature/diamond dual mesh manager

1d remains to be treated

This is related to connectivity <-> diamond-dual connectivity mapping.

Is is now built while building diamond dual connectivity

Some work is still needed, one has to define mapper structures while
building connectivity to avoid (future) incoherence and to give it
flexibility (renumbering an probably helpful for parallelism)

By now, the code only manages diamond cells as polyhedrons, but output
is general (up to the simple definition of a polyhedral cell type)

Rename
`MeshToDiamondDualMeshDataMapper` as
`ConnectivityToDiamondDualConnectivityDataMapper`
which is correct

This data mapper is now available through the
DiamondDualConnectivityManager and is built when connectivity is
constructed

The construction of this mapper is still completely independent of the
mesh construction itself which is bad since same assumptions are made
twice...

It should be actually constructed at the same time allowing for
instance easy renumbering. This should be done soon... hopefully...

Actually one avoids some useless copy/paste

It was actually wrong for all dimensions (not only for 1D)

Thanks to clang-10

primal (cells+nodes) -> dual (nodes) seems ok.

However looks like diamond mesh is buggy in 1d. Just boundary
references or more?

These mechanisms are designed to manage diamond meshes/connectivities

The main idea is that the diamond mesh is stored as long as its
primary mesh lives, and can be retrieved easily.

The same mechanism is defined for diamond mesh connectivities. Thus in
a moving grid context, the only required calculations will be the
definition of the diamond mesh's vertices coordinates.

Recall that diamond meshes are just meshes so all meshes'
functionality apply to them.