We are relying more and more on C99 math functions. On C89 systems where
those functions are not available our own custom versions of those
functions are used instead. So far these has been spread across the code
base. This commit gathers them in the same file and introduces the
proj_math.h header. The build system checks for C99 math functions. If
not found the proj_math.h header make sure that C99 functions are
defined as their pj_ equivalent.

Ideally proj_math.h is included instead of math.h. This removes the need
for any checks against HAVE_C99_MATH in the code making it easier to
read.

For this commit the functions hypot, log1p and asinh has been taken care
of.

When transforming coordinates outside the grid model the deformation
operation failed spectatularly. This is now fixed by checking that the
coordinate is inside the grid. If it isn't an error is returned and a
debugging log message is issued.

Closes #934

* Avoid using angle brackets for PROJ headers.

Switching from #include <proj.h> to #include "proj.h",
and correspondingly for projects.h and proj_api.h,
reduces the risk of accidentally picking up a system
installed older version of the header while building
a new version of PROJ.

* Also handle geodesic.h

The initial approach taken in the deformation operation was not
geodetically sound. The deformation model grids were required
to be indexed in lat/long space with the velocities in the grids
being in cartesian space. This is quite confusing and it is not
a normal way of making deformation models. The usual approach is
to keep everything in the east, north, up, or ENU, space. We adopt
that tradition in this commit. The velocities are still applied in
cartesian space which requires that the grid-velocities are
converted from ENU space to cartesian space. As a consequence of
this change the operation is changed so that it only works in full
3D mode. That is, both horizontal and vertical grids need to be
applied.

The inverse operation is changed slightly to accommodate the
now fully 3D transformation. In it's present form it is a
modification to the original algorithm that also includes the
vertical component in the iteration. This is necessary to get a
proper mapping from ENU to cartesian space in the loop. The
vertical component is overwritten with the initial z-correction
at the end of the loop. This approach is not completely accurate
and will introduce errors, especially when doing many roundtrip
calculations, but it seems to be good enough for a few roundtrips.

The PJ_ENU data type is re-introduced to better communicate the
what state the grid corrections are in throughout the code.

Improve error messaging for cct and gie, and do some clean ups in the ellipsoid handling - partially to squash bugs, partially to improve naming consistency which, in turn, improves the readability of the ellipsoid handling code.

Renamed functions:

pj_inherit_ellipsoid_defs has been renamed pj_inherit_ellipsoid_def, while pj_calc_ellps_params has been renamed pj_calc_ellipsoid_params.

The code in get_opt (part of pj_init.c), which handles whether or not an ellipsoid definition should be dragged in from proj_def.dat, has been rewritten. I suspect this was buggy beforehand, and at least the new code is easier to follow (although it may be slightly slower, which is not really a problem as it sits in the setup code, and hence is executed only once).

* Removed remaining traces of the builtin selftest system. Moved all functionality to test/gie

* Updated Appveyor and Travis build scripts

* Another appveyor script update

PJ_OBS eliminated, API adjusted to reflect that we now have only one 4D data type.
2 new API functions added to determine output types of a PJ.