xDeltaMemory use deprecated (for g++ > 10) malloc hook. Add guards. To
be solved differently.
xDeltaTime uninitialized stuff in some get function ans some warning
about the same problem in the No version

This bug appears when using new version of g++ that needs clear context
jump to provides hard optimizations. GaussLegendre1D function lack of a
returned value despite declaring returning a int. G.L. find that
declaring that the function do not return anything (void) solve the
problem. G++ optimization works well and code jump out of the switch
properly.

Based on work initiated by G. Legrain.

Interface between eXlibris and Matlib material library ("lite" version can be  downloaded here:
https://git.gem.ec-nantes.fr/MatLib/Lite).

To compile this interface:

1) Download and compile Matlib. It must be compiled using the add_definitions( -DMATLIB_USE_MATLIB_NAMESPACE)

2) Install Matlib in a /my/path/to/matlib/ such that libraries are installed in /my/path/to/matlib/lib and
include in /my/path/to/matlib/include. Path to sources /my/path/to/matlib/src will also be necessary

3) Add

if(USE_MATLIB)
    set(MATLIB_PATH "/my/path/to/matlib/src will also be necessary"  CACHE INTERNAL "Matlib install path")#
endif(USE_MATLIB)

to the LocalConfig.cmake file. The line "is_not_installed ( USE_MATLIB )" (which is by default activated in the
 template LocalConfig.cmake of GeMUtil) may eventually need to be commented

4) Set BUILD_XINTERFACE_MATLIB and USE_MATLIB to "ON" in the main CMakeLists.txt

5) (Try to) compile !

To use it in In your code:

1) You need to declare a

xinterface::aomd::xAttachedDataManagerAOMD<std::vector<xinterface::matlibinterface::xMaterialTwoStates>>

which will store some xMaterialTwoStates at each Gauss points

2) Each xMaterialTwoStatesInterface (defined in) contains two matlib::MaterialState, corresponding to the previous
and current material state

3) Still in xMaterialTwoStatesInterface.h, you will find classes to manipulate theses states. In particular, some
important classes are:
  - xInitVectorMatLibTwoStatesToAttachedDataManagerAOMD: must be used with an ApplyCommandOnIntegration rule to
  initialize the states
  - xMatLibStandardMaterialStateUpdatorVectorTwoStates: to update the material states at each Gauss points
  - xMatLibLipschitzMaterialStateUpdator: same, but update only softening variables, in the framework of the Lipfield
   regularization (an appli illustrating the implementation of the Lipfield approach should come soon)
  - xEvalVectorMatLibStandardMaterialTangent: evaluator of the material tangent

4) xEvalFromMatlib.h contains several evaluators to access the quantities stored at GaussPoints and use them in eXlibris.
For now they can be used to access scalar or tensorial matlib gradients, fluxes and internal variables (maybe evaluators
corresponding to vectorial quantities should be added ?)

5) xInterfaceMatlibToExlibris.h contains classes which are used by the previously mentionned classes. Basically, provides
sgome tools to read and/or write from/to matlib arrays

6)  xMatlibHelpers.h some helper functions to parse a material file and create Matlib objects

Note that for objects dealing with tensor 2 or 4 (example : xEvalVectorMatLibStandardMaterialTangent, evaluators in
xEvalFromMatlib.h), some builder functions are provide to instanciate the correct template object, which depends on the
problem dimension. In the case of the xEvalVectorMatLibStandardMaterialTangent, it can be used directly inside your main
appli (but special care must be given to the problem dimension), otherwise a xFormBilinearMatLibStandardMaterialTangentFactory
is provided in the interface to create the corresponding bilinear form (which is btw the only thing which is necessary in most
cases).

Does the same thing as xAssemblerLumped, but assemble the terms of the
lumped matrix in a vector.

- Added a getFileName() function, which calls the getFileName() of xExportManager
(which has been made const)

- Added an exportDebug function, to export values managers. In the future it could
eventually be overloaded to export other debug files. A good example could be
xCSRVector or matrixes, but it would introduced a dependency of xExport on xLinalg

- Added a debug flag with a setDebugFlag function to add some debug output

- Now the exportOnSpace functions automatically set the number of splits of the
xExport to 1 (similarly to the old MyExport function of DamageGrowthBase in TLSImplicit)

In the previous version, the values of some labels coming from the xParseData
where imposed (so basically xPostProcessingManager could not work if some
particular labels were not defined in the xParseData). The API has been modified
to be usable with any custome labels.

An error was introduced in commit 4727e73e... "tagger" should be a member
of xEvalTLSAdimLSFromLevelSetAndLCFront, created and modified in this class,
and not an object coming from outside.

Added new class xPostProcessingManager, which was previously in the XTLS/TLSElementbased
appli (under the name PostProcessing).

The main goal of this class is to encapsulate three xexport concepts:
- The xexport::Export function
- The xexport::xExportManager class
- The xexport::xExportSensors class

through the use of two main functions:

- exportOnSpace : export a field/mesh/a level set with the Export function,
using the frequency defined by the xExportManager. Note that if the field is a
vector or tensor field, a given component can be exported by adding an extension to the
name of the field in the parsed file. For instance, if a vector field named "displacement"
is exported in the code, it can be exported by adding the name "displacement" in the
export_manager field of the parsed file, but the first (second/third) component can also be exported
b adding "displacement_1" ("displacement_2", "displacement_3"). Same for tensor fields (_11, _13, _23, etc)

- exportOnTime : write a scalar quantity in a text file, using the xExportSensors class

The saveMesh, saveField and saveDomain function from the former class PostProcessing were kept, and could
be used in the future to implement restart.

When dealing with large number of cores with mumps distributed interface,
if the size of the problem is small, poor performance are obtained with
mumps library. The fact that matrix is presented in distributed format
alleviate some internal optimization (available with centralize matrix
format) and mumps among other has difficulty then to estimate its memory
needs. This lead to underestimate memory evaluation during analyse phase
which stop computation during factorization with a -9 error. Even if
this memory issue is bypassed CPU time increase with number of cores
when more then needed are used.

In this commit a extra parameter ratio_reduce_comm_ is added to
connectMatrix method of xLinearSystemSolverMumpsDistributed class.
It correspond some how to an "ideal" ratio between the number of core to
use for a given problem size "n". mx=ratio_reduce_comm * n is giving a
roughs estimate of the maximum number of cores needed by mumps
computation for a "n" size linear system. If the communicator given to
mumps interface is larger then this mx estimate, only mx cores will be
used with mumps. In this case interface will allocate its own memory to
store matrix terms and user will have to use reduceMatrices() if he
updates value in matrix storage connected to the interface. Because in
this case interface groups matrix terms in the reduced set of core
participating to mumps computation. Thus some communication need to be
done every times terms changes in connected matrix. This alleviate some
how the nice unique memory space shared between the connect matrix and
mumps.

When the communicator given to mumps interface is smaller then this mx
estimate the interface behaves has before. Same if ratio_reduce_comm_ is
null.

This solution represent an intermediate between centralized and full
distributed matrix format for mumps. If ratio lead to mx=1 a even more
clearer implementation would be to switch to centralized  matrix format
for mumps. TODO.

For now memory consumption is not optimized as regrouped terms on process
that hold matrix may be duplicate (i.e. a term i,j may appearers many
time due to its presence in many process). Its not a problem for mumps
as it will sum them but it cost memory. Reducing this consumption is not
so easy to do. Communication buffer have to transfers all those
terms so their size may be important anyway. TODO.

After some discussion with other contributors the resize method of
class xDenseMatrix have been changed so that it initialize its newly
allocated memory with a defined value. By default this value is zero but
it can be changed.

Now use of resize guaranty a defined state for matrix term which avoid
some issue like having nan in some location that cannot be cleaned out
by use of *= operator with zero argument.

Due to GIT mystery files xAttachableXXX.* were moved to target directories but not remove form xFEM/src. Now they are moved to attic.

    	- xAttachableString.cc 		-> xDoubleCut
    	- xAttachableChar			-> xInterface/AOMD 	(still used in TLSImplicit)
    	- xAttachableGP			-> xInterface/AOMD 	(still used in TLSElementBased)
    	- xAttachableEntitiesVector	-> xTLS 				(still used in TLSExplicit)
    	- xAttachableEntitiesSet		-> attic

This commit pass from () to [] operator for LOCALVECTOR concept of
xAssembler concept. This is opening usage of assemble_vector method
to a wider range of container types. LOCALVECTOR may now be a
xCSRVector or a std::vector for example. xFemVector having both
operator remains functional (maybe () operator should be removed now ?).

Some comments are added to try to clarify LOCALVECTOR and LOCALMATRIX
concept.

- Mark xFEM/xAttachableXXX class as deprecated (they shall be moved or removed).

xGeom:

- change use of xAttachableChar : replace const unsigned int tag_nodes  by a const xAttachedDataManagerAOMD<char>& in constructor of xLevelSetToCGALAndTag.

xTLS:

- change use of xAttachableChar : replace const unsigned int tag_nodes by a xAttachedDataManagerAOMD<char> in:
		- TLSGeomInterfaceSignedVectorLevelSet,
		- reInitLevelSetFromFrontCGAL2,
		- xEvalTLSAdimLSFromLevelSetAndLCFront
		- xRefCutToIsoCGAL

This is removing the statics and encapsulate things

GP data manager is now encapsulated into a class
xIntegrationRuleStoredDataManager from which all
xIntegrationRuleStoredxxx class derive. This way xIntegrationRule
is not anymore impacted and when xIntegrationRuleStoredxxx is deleted
every thing is automatically cleaned. xIntegrationRuleStoredxxx is
responsible of the management of attached gauss points to entity.

xIntegrationRuleStoredDataManager encapsulate the DATAMANAGER thus in
future switching to others things will be easy. It retake almost the
same API as DATAMANAGER with other names.

Now that static are removed xExtendShapeFcts had to be modified to store
a reference of xIntegrationRuleStoredxxx so that adding GP to entity is
possible through functor call like before but with a new parameter
passing xIntegrationRuleStoredxxx viewd as a
xIntegrationRuleStoredDataManager. The xIntegrationRuleStoredxxx
instance and the xExtendShapeFcts generator are now more tied together.
This induce that the xSpaceExtendedShape based on generator is tied to
xIntegrationRuleStoredxxx and assemble is now a little more
secure as the field (base on xSpaceExtendedShape) is now in coherence
with xIntegrationRuleStoredxxx explicitly.

Hope I did not break something somewhere. I mean test pass but there is
not much of them on those things ....

Remove use of xAttachableGP in Xfiles. Now a datamanager is added to class to attach Gauss Points data.
    The type xGaussPoints is defined as std::vector<std::pair<xtensor::xPoint, double>> and the datamanager type is datamanager_gauss_points_t (defined in xIntegrationRule.h).
    A static function of xIntegrationRule allows to get the datamanger.

    Example 1:
        agp = new xfem::xGaussPoints;
        xfem::xIntegrationRule::get_gauss_points_datamanager().setData(*e) = *agp;

    Example 2:
        xfem::datamanager_gauss_points_t& _data_GP_= xfem::xIntegrationRule::get_gauss_points_datamanager();
        xfem::xGaussPoints* agp = _data_GP_.getData(*e);

This method pass in revue all the non null terms (topological sens) and
run a functor on them. The functor is expected to have 3 arguments:
- 2 integer i and j that contains row and column index of term.
- one T val corresponding to term's value.
The functor can do anything you want.

This function offers to user a quick way to deal with all traits.
It may be slightly less efficient then calling getMemoryAcces and by
hand pass in in revue terms according to traits (to be checked). It
depends on what you do.

It will be used internally to replace many duplicated piece of code
where looping on all terms is required. It is already in use with
printMatrixMarket method. Has some test do check matrix market outputs
we can already conclude that forEach is validate.

A DeclareInterpolation2 and DeclareState2 is added to xAlgorithm.h in
this commit. The idea is not to use them right away but instead to test
them in your context by switching names (remove the 2 and add
something to old version names). By context here I talk of compiler. For
those who use something else then GNU g++, those new versions have to be
validated because they use the following assertion not in the norm I
think:
The clear method of std::vector do not touch memory allocation.

Thus the glob and loc vectors use memory management a small number of
time (for the first set of key of each space for a priori one element
per space at most). Otherwise the insert is relying on already allocated
capacity.
If this assertion is not verified with other compiler something will have
to be added.

Besides this memory trick the main modification comes from valgrind
study. It shows that xFiniteElement destructor and setKeys count
respectively for 6.44% and 35.49% of 595 call to Declarinterpolation
with a total of 304 640 elements treated (512 per call).
KeysFor interfere in setKeys for 19.08%. As stated already by N.C.,
clearly those computation are too costly compared to the generality or
maintainability that they provides. The adopted solution was to remove
xFiniteElement usage in those functions. That may hurt ... Maybe the
loop on space, glob and loc ingredient may be encapsulate in something
.. or xFiniteElement may be cleaned.

For now those new versions are proof concept. Their performance shows up
more then 20% gain in some application with many declareXXX.

Note that new version pass test successfully.

We had already a begin, end method. Using then with std:distance was a
way to know how many values are created in the xValManager instance. But
has iterator are not ramdom ones, it cost a lot to have this information
that is available privatelly. This comite makes it public by adding this
size method.

Some std::swap have been replaced by call to swap class method to
avoid infinit recursion. Validate by N.C.

A new default parameter is added to xExportGmshMPIIO constructor. This
parameter fix the numbers of files to be generated (see comments in
sources for precise policy).

This addition give a way to split huge results in smaller part more
easily handled with GMSH. It might give also extra performance
for large number of process by enlarging the number of file treated
simultaneously by the file system.

xDeltaMemory class is built in the same spirit as xDeltaTime.
A "start" method capture a state and a "end" method do a comparison with
previous captured state. This comparison give a measure of memory
consumption between those two events.
To be as precise as possible the usual string used to flag measure are
now forcedly used by initAccu method and user must use startAccu,
endAccu with the integer returned by initAccu.

It give result like xDeltaTime as table with parallel statistic and Peak
memory usage. This last information comes from getrusage (like
xMemoryMonitor) and correspond to maximum resident set size. All other
information are related to user request and do not represent the
application true current memory consumption: malloc may have already
reserve 2GB and user vector may use only 1.5GB. This is this last
information that is given by xDeltaMemory.

Only Heap is analyzed.

Behind the curtain:
===================
xDeltaMemory used deprecated GNU extension called hooks. malloc,realloc
and free hooks give a way to set your own feature related to those
function. In our case we want to count what user did ask for allocation.
A ideal solution would be to use the size argument to count. But when
freeing memory we just have a pointer in hand so its not easy to decrease
our counter. Instead xDeltaMemory use malloc_usable_size which demangle the
malloc information related to the accessible memory associated to
pointer given by malloc.  xDeltaMemory over estimate then the real size
asked by the user as  malloc_usable_size return the asked size plus the
padding eventually added by malloc. But this is already a pretty
accurate measure. Compare to xMemoryMonitor or the use of mallinfo here
we place the measure in client application side. The others approaches
can be qualified as system measuring snapshot. And thus they are harder
to use for precise measure of user allocation.

The deprecated aspect seem to last from a long time ... With gcc 8 on
liger it is still available ....

The GNU extension aspect is clearly a limitation. This is not portable !
But all GNU specific aspect has been guarded by __GNUC__ macro so on
other compiler xDeltaMemory will return 0 for all measure.

To measure third party library calls, it will be possible only if
the library is also compiled with a GNU compiler and malloc is in use.
Somme test on liger with mumps show that xDeltaMemory provided almost
the same information as MUMPS itself.

Note that interleaving measure is possible. A specific counter track the
start/end to deactivate hooks outside measuring sequence to avoid any
extra computational cost.

The implementation use static variable ! It is then not currently thread safe.

New atomic test case:
=====================
A small test show how  to use xDeltaMemory and is for now the only
documentation.

TODO
====
doc+xNoDeltaMemory class

xTensor and xMapping library were not managed by any options. For sure
both may/are (I don't know) needed by almost all other libraries. But it
is not the question of "need" but the question of "when" that those new
option answer to.

In many free project the moto to get them in use is
"configure/cmake, make, make install"

Here if we consider that all ours repositories works like that, xFiles
and xTest and ...(Applis) may be compiled separately with steps:
"make install"
Introducing those options gives a way to avoid xMapping and xTensor
compilation all the time. They are compiled and installed when dealing
with xFiles. Then there is no need to compile then for  XTest ....
Actual vision is to use the same GEMUtil CMakelist.txt and switch option.
That introduce this constraint but maybe in future we will split that
file in some peaces : option block, Xfiles, xTest, APPLI.

class xBoundary was only used as a parameter to some
Mechanics::TreatmentOfNatEnv that was never actually used and which was
passed around via a member of xData. It is nothing more than an early
implementation of xSubMesh that was passed around via cut and past for a
long time ... Therefore, xBoundary is now made obsolete and the files
xBoundary.h/cc are moved to xFEM/src/attic.

all its' use will be removed from xTest.

Note : My first clang-format related bug.
The file xDistanceNearestPointGenerator.h need to be included before
xDistanceNearestPoint.h, otherwise some test case can't compile !!! indeed,
it add some overload to cgal AABBPrimitive that needs to be visible for
template instanciation that can take place via  xDistanceNearestPoint.h.
But clang-format messed around and I had to force the inclusion of xDistanceNearestPointGenerator.h before xDistanceNearestPoint.h, by including it at the
beginning of xDistanceNearestPoint.h, and preventing clang-format to reorder
the include by inserting some comment.

Xfiles_dependence.dot that contains the "handmade" dependancies graph
between the libraries in xfiles have been updated, based on the
CMakeLists.txt.

Main changes :
- A new library xGeomTools is added in xGeom.
  *This library is meant to collect "simple" geometrical classes/functions.
   By "simple" we mean that they dependent only on xtensor, and xtool.
  *All the classes and functions of xGeomTools are in namespace xgeom.
  *For this commit it contains :
   xBoundingBox.h/cc, xOctreeGrid.h, xRegularGrid.h/cc, xSimpleGeometry.h,
   moved from xTensor or xFEM.
  *Previous library xGeom is split in two libraries : xDistanceNearest and
   xScanElement in respectivevly xGeom/xDistanceNearest
   and xGeom/xScanElement,
  *The old xGeom library do not exist any more.
  *Note that the 3 libraries contained in directory xGeom populate
   the namespace xGeom.
  *Global build option BUILD_XGEOM is removed.
  *Global build option BUILD_XGEOMTOOLS, BUILD_XDISTANCENEAREST,
    BUILD_XSCANELEMENT are added.
  *xGeom/CMakeLists.txt is removed
  *xUTil/cmakeUtil :
   FindxGeomTools.cmake, FindxDistanceNearest.cmake, FindxScanElement.cmake
   added, FindxGeom.cmake is removed.
  *xAnalyticalSolution, xCrack, xDoubleCut, xLegacySimpleCut, xDomainDecomp,
   xExport, xExt, xFEM, xInterfaceAOMD, xMeshInterface, xOctree, xMapping,
   xTLS, now depend on  xGeomTools.
  *xOctree and xTLS now depends on xDistanceNearest
- xBoundingBox :
  *added member functions  inclose(), now used in xMesh, xSubMesh
  and xLagrangeMapping.
  *added default constructor and constructor for 2 xPoint.
  *default constructor now build an  empty "bb"  by havinh min(i) > max (i)
- xRegularGrid : dependencies to xMesh are removed.
- xMesh.h :  part of previous xOctreeGrid that was dependent of xMesh are
  no directly implemented in xMesh. (see xMesh::createGrid() and
  xMesh::locateElement)

Miscanelous changes along the way (removing useless dependencies)
- xValue.cc : removed "useless" inclusions of "xApproxFunction.h",
  "xField.h", "xLevelSet.h", "xSpacePolynomial.h", "xTensors.h",
  "xTensorsPtr.h" "xVector.h" as well as useless using AOMD::mEdge
  and using AOMD::mEntity.
- xValue.h : removed useless inclusions of  <set>,
  <boost/graph/adjacency_list.hpp>, <boost/graph/connected_components.hpp>,
  "xTensorsPtr.h", "xDebug.h", "xNearestNeighborInterface.h"
- xValue_imp.h : removed useless includes "mEdge.h" and "xGeomeElem.h"
- xValueManager.h - removed dependencies to xMesh.
- some of AOMD include cascading in other files because of the previous
  removed inclusion were putting std::string in global namespace.
  std::string is now added in the following files :
  std::string xExport.h, xExportEnsight, xExportGmsh.h
  xExportTranslate.cc/h, xField.h, xFEM/src/xSpacePolynomial.h.
- xData.cc inside void xData::ReadInfo(const char *filename),
  unused variable xBoundary crvboundary; is removed.
- all modified and added files are clang-formatted.

xGeomElem code is simplifyed (and improved ?) in the following way :

- All the members now have version with the correct camelCase style. The old version are kept (for example GetDetJac is "cloned" to getDetJac), but are marked as "deprecated" in the their doxygen documentation. I tryed to use the [[deprecated]] attribute on them but unfortunatly, it's c++14 and we still can't use this version of the standard. I kept all the old version there since xGeomElem is used all over the places, but I would like to remove them in a near future ...

- xBoundingBox xGeomElem::getBoundingBox() const take the place of void xGeomElem::GetBoundingBox(xtensor::xPoint& min, xtensor::xPoint& max) const.

- The implementation take advantages of improved interface to xMapping.h
  for example :
  xtensor::xPoint xGeomElem ::getCDGxyz() const
  {
   double u, v, w, x, y, z;
   mapping->COG(u, v, w);
   mapping->eval(u, v, w, x, y, z);
   return xtensor::xPoint(x, y, z);
  }
  is replaced by
  xtensor::xPoint xGeomElem::getCDGxyz() const { return mapping->eval(mapping->COG()); }
  and
  void xGeomElem::setUVWForVertex(int inod) which was almost 200 lines
  is replaced by
  void xGeomElem ::setUVWForVertex(int inod) { uvw = mapping->getMappingVertex(inod); }
  where mapping->getMappingVertex(inod); just return data that where already in xMapping.

- setting/clearing  the mapping or integrator members of the class was complicated because we have to keep track of differents life  time for  these pointers depending if they where defaulty allocated or pass by the user and eventulaly shared by differents
  xGeomElem. This is now simplifyed using a unique_ptr and classic ptr, allowing to use the implicitly declared destructor for
  xGEomElem.
  This pave the way for better mapping management in the  futur (I'm thinking of high order mapping that would be expensive
  to construct, that we might wan't to store in the builder ...)

- we now have move constructor, move assignment and swap for xGeomElem, making them more usable in standard containers.

Note on xGeomElem :
 - I think set/getOrientation are not very usefull, probably bug prone, and I think they should be removed.
 - I'm not sure we still need the integrator to be included in the xGeomElem, Integration behing performed in most cases using an
   xIntegrationRule  and xCommandOnGeomElem that could set directly the current point instead of setting it using both xGeomElem::setIntegrationPointNumberForDegree and xGeomElem::setUVW(int ipt)

4 access functions have been added in class xMapping to access data that where already there, but not accessible outside xMapping.cc :
   -size_t getNbMappingVertices() const;
   -xtensor::xPoint getMappingVertex(size_t i) const;
   -static size_t getNbMappingVertices(xReferenceElementType type);
   -static xtensor::xPoint getMappingVertex(xReferenceElementType type, size_t i);

First, I added a test directory inside xFEM for xFEM Atomic test that was missing. (As usual Atomic test means that the test do not need other library that the current tested library dependencies)
A new Build option is added, corresponding to the xFEM Atomic test  : BUILD_XFEM_TEST. It must be set to ON in your parent CMakeFiles.txt for this test to be builded, thanks to the Xfiles/CMakeLists.txt that will add the subdirectory xFEM/test to the build if BUILD_XFEM_TEST is set to ON

In xFEM/test I added two tests cases :
testxOctreeGrid and testxRegularGrid, along with there references.

Some other tests from in Xtest/xfem-seq-test for example could also be moved here.

In both files some variable were potentially not initialized and
nevertheless used for some computation.
After checking with N.C. for xLagrangeMapping.cc the case were
knots.size() is null is impossible => assert. Then a simple init with
first point remove the warning and set without ambiguity x1,y1,z1.
For xMapping.cc the switch was not defaulted and thus DetJac may remain
unset. Setting it to 1 and put a default case in switch solve the prb.

xFEM/src/xOctreeGrid.h is a new file. It introduce a octree grid search
  structure to use in place of the AOMD::octree that was used in xMesh
  for the locateOctree members functions. It permits to construct an octree
  search structure on top of a collection of mesh entity.

xFEM/src/xRegularGrid.h/cc has been modifyed so that :
 - it uses the xBoundingBox class.
 - The member function name have been changed to reflect the camel case
   convention, common to the rest of the xFEM library.
 - getElementsForPoint now return a vector of {element, localcoordinate} pair,
   so that the local coordinate of the target point in each element that
   contains it is now accessible.
 - The code have been clarifyed and simplifyed.

xBoundingBox.h :
  - added 2 member function in xBoundingBox :
   /// return the center of the bounding box
   xPoint center() const { return (min + max) * 0.5; }
   /// return a vector from min to max
   xVector<double> diag() const { return xVector<double>{min, max}; }
  - Note that following a discussion with A. Salzmann, xBoundingBox could
    be moved in a near futur to namespace xgeom and the file might be part
    of a new library (xGeomTools maybe)

xFEM/src/xMesh.h/cc has been modifyed so that :
  - It uses the xBoundingBox class were usefull, implying some interface
    change :
     * std::pair<xPoint, xPoint> compute_bounding_box(mEntity* e)
       is changed to :
       xBoundingBox compute_bounding_box(const mEntity& e);
     * void compute_bounding_box(xPoint& min,xPoint& max) const;
       is "deprecated", but is still there during the transition.
       it is replaced by :
       xtensor::xBoundingBox compute_bounding_box() const;
  - locateElementOctree and locateElement have changed interface,
    reflecting the changes in xRegularGrid and the use of xOctreeGrid instead of
    AOMD's octree.
  - Better control of the search structure in xMesh, since now the octree or
    the regular grid can both be cleared, updated or accessed by calling
    respectively xMesh Members   createOctree(), clearOctree(), getOctreeGrid(),
    createGrid(), clearGrid(), getRegularGrid.
  - The search structure pointers are now managed in a unique_ptr.
  - xMesh::copyMeshInternal now copy the search structures if needed instead
    of throwing.
  - AOMD_SharedInfo.h, autopack.h, OctreeCreate2.h (from AOMD) are not
    included anymore.

xCrack/src/CrackPostpro.cc,  xCrack/src/ExportSensors.cc/h, modified so that it
  reflect the change in xMesh::locateElement

 xExport/src/xSensors.cc/h :
  -modified so that it reflect the change in xMesh::locateElement,
  -Trellis_Util::mPoint replaced by xtensor::xPoint
  -small changes to simplify the implementation
  -clang-format first the first time I think.

xInterface/xOctree/src/surf2LevelSet.cc/h
  -modifyed to use xBoundingBox
  -surface2LevelSet::getBB(xPoint&, xPoint&) is replaced by
   const xBoundingBox &getBB() const { return BB; }
  -surface2LevelSet members xPoint BBmin, BBmax are replaced xBoundingBox BB;
  -a bug was found in the process :
   In surface2LevelSet::createMeshBBox that create an xMesh out of grid,
   the grid point coordinate were computed as :
    double xyz[3] = {BB.min(0) + i * elemSizeX, BB.min(1) +
                                 j * elemSizeY, BB.min(2) + k * elemSizeY};
   instead of :
     double xyz[3] = {BB.min(0) + i * elemSizeX, BB.min(1) +
                                  j * elemSizeY, BB.min(2) + k * elemSizeZ};
   The bug is corrected, but reference of test case
   xinterface-xoctree-test/surface2LevelSet had to be changed.

All modifyed files have been clang-fomated.

xMapping now include xTensor/src/xBoundingBox.

The following virtual member function of xMapping have been added.
They all have default implementation in terms of the one existing before.
They mostly simplify code when using them, and do not need to be implemented i
in derived class (but could for optimization purpose)

 virtual xtensor::xPoint eval(const xtensor::xPoint &uvw) const;
 virtual tensor deval(const xtensor::xPoint &uvw) const;
 virtual bool invert(const xtensor::xPoint &xyz, xtensor::xPoint &uvw) const;
 virtual double jacInverse(const xtensor::xPoint &uvw, tensor &invjac) const;
 virtual double detJac(const xtensor::xPoint &uvw) const;
 virtual bool inReferenceElement(const xtensor::xPoint &uvw) const;
 virtual xtensor::xPoint COG() const;
 virtual double pushBack(const xtensor::xPoint &uvw, size_t vsize, vector3d *vec) const;
 virtual double pushBack(const xtensor::xPoint &uvw, std::vector<vector3d> &vec) const;
 virtual double pushBack(const xtensor::xPoint &uvw, size_t vsize, tensor *tens) const;
 virtual xtensor::xBoundingBox boundingBox() const;

interface change in xMapping :
    virtual bool interiorCheck(const xtensor::xPoint &p, double u, double v, double w) const; changed to virtual bool interiorCheck(const xtensor::xPoint &p, xtensor::xPoint &uvw) const;

 Modified files :
   xMapping/src/xMapping.cc
   xMapping/src/xMapping.h

 and
   xFEM/src/xRegularGrid.cc
   modified to reflect xMapping::interiorCheck interface change

 in file xTensor/src/xBoundingBox.h
 added class xBoundingBox in xTensor.
 it helps to manipulate bounding box thanks to the member functions,
 and will permit to remove some code duplication regarding bounding box
 intersection or checking if a point is inside a bounding box,
 compared to a model were we just pass around two xPoint.

 added member function in class xtensor::xPoint :
  double & operator [] (int i);
  double operator [] (int i) const;
  xPoint operator / (double other) const;
  xPoint& operator /= (double other)
  xPoint& operator -= (const xPoint &other)
  bool operator == (const xPoint & other) const

 xTensor/src/xPoint.h   clang-formated

This commit remove usage of AOMD EntityHashKey and EntityEqualKey for unordered_map
container. Using default hash and equalkey based on address (the key is a
pointer) is a priori more efficient.

This commit is adding template function setParmetisPartitionWithWeight that
use a set of weights per element to optimize ParMetis partitioning based on
multi criteria (the weights).  The template parameter (an int) is fixing the
number of weights per element. The interface is kept simple. Only an extra
xAttachedDataManagerAOMD is used to passe weights set per element.

No test case for now but it have been heavily tested in some apps.

This function is using almost the same algo as the one used for
setParmetisPartition in the cc file. It is rather dirty (code
duplication) but efficient.

It add also a new dependency in terms of cmake. xInterfaceParMetis must
now be added in cmake to use xLoadBalanceTools. But anyway from my point
of view it should already be the case. Normally xInterfaceParMetis should
embedded ParMetis and in cmake finding metis/parmetis lib should not be
done.... Modern cmake would do even more by setting all this dependency
setting for you .....

 * Add a getPoint function to simplify xPoint creation from mVertex (no
   need of vector like getPoints which is more general).

 * make alive commented (in xMesh) printMesh and printEntity functions.
   They will certainly move to AOMD interface one day. But for now
   please let them stay active has I use then for debugging in my
   application. No time to do a test case on the subject.

 * To avoid warning on unused variable clean creation of object returned
   by many function that are not used afterward.