start work on #412
 - introduce fmemopen on macosx to attach a file descriptor to a memory buffer
 - add ParseGeoFileFromMemory() to read geo files directly in memory (necessary
 for Abdoulaye to generate the local subdomain meshes
Merge branch 'develop' into feature-gmsh-in-memory
up #412 : implement in-memory setting/getting gmsh data structures
 - write geo data to gmsh to generate meshes in-memory
 - read gmsh msh files : 2D only for now
 - works only when worldComm is sequential (e.g. worldCommSeq)

use option `gmsh.in-memory=true|false` to use this feature
move forward submodules
up #412 : add missing Gmsh header
Merge branch 'develop' into feature-gmsh-in-memory
added possibily missing gmsh header files
Merge remote-tracking branch 'origin/develop' into feature-gmsh-in-memory
up #216: rename static data member using S_ prefix rather than M_
see https://github.com/feelpp/feelpp/wiki/FeelppCodingStyles#declaring-variables
up #417 : added number of boundary faces in the mesh
up #412 : added tetra and hexa element for in-memory gmsh support
now mesh application (see #417) reports properly the number of volume elements
up #412 : add physical names (if any) in mesh data strcture
add sublime text project file
Merge branch 'feature-gmsh-in-memory' of https://github.com/feelpp/feelpp into feature-gmsh-in-memory
add cpp macros to check for GMSH version
fix #418 : add cpp marcos to check for Feel++ version
useful for projects requiring recent features and to avoid breakage in travis
which might use an older version of Feel++
fix #412 : various cleanup
ifdef with respect to Gmsh availability some parts of the code
now Geo files can be read from memory on Macosx and Linux thanks to fmemopen
now msh files can be read in sequential directly from Gmsh data structures
Merge remote-tracking branch 'origin/develop' into feature-gmsh-in-memory
up #412 : fix compilation
start workinh on ChangeLog for 0.99