- new fltk/openTreeItem and fltk/closeTreeItem api functions to manipulate the menu through the api

get{Edge,Face}Number -> get{Edge,Face}Tags for consistency + remove experimental warning, as this is here to stay

make edge identifiers size_t + fix arguments of mesh/getEdgeNumber + add mesh/getFaceNumber (these should be renamed...)

new (probably temporary) gmsh/mesh/createEdges and gmsh/mesh/createFaces (until we provide a facility to simply create and store mesh edges/faces as elements)

interface old "geometrical" boundary layers from the built-in kernel in the api; these can still be useful for modelling (compared to classical "mesh-based" boundary layers, which do not create model entities and are simply meshing constraints)

- make sure not to break backward compatibility (coef should be > 0; .geo files encode direction in type)
- add "Beta" law in api

initializing the api now sets General.Terminal=1 (to print messages by default) and General.AbortOnError=2 (to throw an exception as soon as an error happens) - cf. #1043

- add "geo" versions of add/RemovePhysicalGroup in anticipation of move of "master" physical group definition in GModel (we will need to keep the built-in kernel defintion as well, since built-in CAD operations track physicals)
- more explicit mentions of CAD kernel in api docs

add patch version in API version: it's not strictly necessary (we don't break the API between patch releases), but it makes things simpler.

rationale: with non-breaking API changes (e.g. adding a new function) one had to use gmsh/option/getNumber("General.Version") to check the Gmsh version; using the same numbering for the API and for Gmsh means one can simply examine the API version.

Fixes #997

new optional parameter in geo/addCurveLoop to reorient the curves if necessary + throw exception in api when curve loops are wrong (cf. #993)

setTransfiniteAutomatic() automatically sets the transfinite
attribute on curves, surfaces and volumes when possible. The
objective is to automate a task (setting transfinite) which is
very tedious on large CAD models (hundreds of curves), and to
help automatic quad meshers by preprocessing the trivial patches.
The number of points on curves is automatically determined according
to the sizing constraints (same number as when generating the vertices
on curves). The number of points is kept coherent between adjacent
quadrilateral surfaces by computing the topological chords where
possible, and using the averaged values on the independent chords.

Some limitations:
- It is not possible to automatically and robustly deal with
faces with more than 4 edges, even if we could choose 4 corners,
as it would create T-junctions and then the automatically propagated
constraints may become inconsistent (limit cycles). It is still
possible to deal with a subset of these cases, but it is lot of work,
much more than this commit.
- In the quadrilateral faces, the angle corners are computed from the
curve tangents but do not use the face normal, so large concave corners
are not rejected with the current approach.
- Currently, the points are uniformly distributed on the transfinite
curves. It should be possible to detect existing transfinite curves
with non-uniform distributions and propagate them.