xfem: xStringManager using hash function+ size_t for xValKey

This commit is a proposition to issue 19. In parallel having same Id associated to a string is fundamental. It permit to identify xValKey properly in between process. This commit propose to use hash function (std one) to associate to string (DISPLACEMENT_X, HIERACHICAL_1, ...) a unique number, the hash of the string. To be unique the T type that must be used with xStringManager must be relatively large to avoid hash collision. Somme attempt with short (original type of xValKey::Geom/Phys) where unsuccessful.

This drive to use size_t (the type returned by the std hash function) for xValKey::Geom/Phys (Maybe the intermediate int type might work). This change is a rather big decision for the library has it rise memory foot print from 4 bytes to 16bytes for xValKey::Geom/Phys....

Concretely a new ids_size_t have been added to xValKey to set type of Phys and Geom. This type is now used everywhere to avoid previous situation where short and int where used for the same information. Now for collision free hashing ids_size_t=size_t. This old mixed type give now with size_t, error if correct type is not used. In Particular in xKeyInfo and xSpace change to ids_size_t is now mandatory. Many other place have been changed so that this new type choice for xValKey::Geom/Phys do not induce error. Has it is hard to track where those types have to be imposed this commit is done in an branch so that every one have the opportunity to check with is own apply.

Note that due to issue 35 for example, the xStringManager default usage is to use the old sequential mechanism (no hashing). This is why xZone, xEnv, xDomainStringManager are all using xStringManager the old way. Only xKeyInfo explicitly use a hash function given has a type in the declaration for its xStringManager.

People may roll back to old situation by simply set ids_size_t to short and declare in xKeyInfo: typedef xStringManager<xValKey::ids_size_t > string_manager_t;

Please vote