This PR aims to fix incomplete check of the consistency of edge tag inside tetra

Reminder of Mmg data structures

We don't store the edges in a "unique" way inside an edge array.
Instead, each tetra is able to retrieve, for each of its edges, "geometrical" informations (is the edge a reference edge, a non-manifold one, a ridge one...). These informations are stored under the form of binary tags inside a MMG5_xTetra structure:

• the MMG5_xTetra structures stores the edge tags inside its tag array for each of the 6 tetra edges;
• if a tetra has a boundary face, the xt field of the tetra stores the position of its MMG5_xTetra inside the xtetra array.

Thus, for an edge shared by multiple tetras, bugs may lead to inconsistencies (differences) between the tags stored by tetra, while tags should be identical in all the tetra that are sharing the edge as soon as the edge is marked as MG_BDY inside the tetra (boundary edge belonging to a boundary face).

For illustration, on the attached picture, if we suppose that the edge p-q is the $4^{th}$ edge of the tetra number $1$ and the $2^d$ edge of the tetra $2$, as soon as the edge belongs to a boundary face in both tetra (edge marked MG_BDY in both tetra) we should have:

mesh->xtetra[mesh->tetra[1]->xt]->tag[4] == mesh->xtetra[mesh->tetra[2]->xt]->tag[2] 

Debug function MMG3D_chkmeshedgestags

The MMG3D_chkmeshedgestag function is provided for debugging purpose and called by the MMG3D_chkmsh function at the end of the remeshing process (during the mesh packing) when debug mode is enabled (-d command line option).

Incomplete implementation

Initial implementation calls the MMG5_hashEdgeTag function which cumulates the edge tags inside a hash table :

• if the tag of the edge is 16 the first time the edge is hased, the function stores the edge with tag 16 and returns 16;
• if the tag of the edge is 1 or 17 the second time the edge is hased, then the tag of the edge inside the hash table is updated to 17 (acumulation of binary tags tag |= 1 or tag |= 17) and the function returns 17;
• if the tag of the edge is 16 the third time the edge is hashed, then the tag of the edge inside the hash table stays 17 and the function still returns 17.

In consequence, if the edge p-q is processed first from the tetra 1 in which it has tag 16 (MG_BDY) then from the tetra 2 in which it has tag 17 (MG_REF & MG_BDY), the implementation in the develop branch fails to detect the lack of consistency. If tetra are processed in reverse order, the inconsistency is detected because we store first the tag 17 in the hash table, then we compare the tag stored inside the xtetra of tetra 2, which is 16 with the value stored in the hash table (17).

Fix

The current PR proposes to replace the call to the MMG5_hashEdgeTag function by a call to the MMG5_hGet function. This function:

• returns 1 if the edge is founded in the hash table and stores the associated tag (so we can compare it with the tetra edge tag);
• returns 0 if the edge is not founded: in this case, we call the MMG5_hEdge function to store the edge and the associated tag.

It allows to detect inconsistencies independently of the order in which we process the tetra.