…ing authname

…instead

…nd units

…e area of use argument, and make createFromUserInput() recognize init=epsg: / init=IGNF: in legacy mode, that is when proj_context_get_use_proj4_init_rules() is used

…remove the data/epsg and data/IGNF files

I've found that if building PROJ with lto, but GDAL without lto, exceptions
thrown in PROJ are not properly captured by try {} blocks in PROJ C API,
and unexpectedly go back up to GDAL.
Might be a defect of the particular compiler I use (gcc 5.4 Ubuntu 16.04)

- proj_obj_create_projected_XXXXX() are renamed to
  proj_obj_create_conversion_snake_case() and just instanciate
  a Conversion object
- Advanced manipulation functions are moved to a dedicated
  section at bottom of proj.h
- New C API needed for GDAL OGRSpatialReference

… test cases

We store the PJ_CONTEXT* in the PJ_OBJ objects, but this
might cause issues in multi-threaded uses.
For example, before this change, let's imagie:
- a PJ_OBJ is created in thread A with a PJ_CONTEXT that
  is specific to this thread A
- PJ_OBJ is transfered to another thread that operates on
  it. It might thus use the PJ_CONTEXT that was TLS(A)
- in the meantime thread A does completely different things,
  but still operate on its PJ_CONTEXT. We might get a
  concurrent use of the PJ_CONTEXT despite working on
  different PJ_OBJ

Another situation is when using constructor functions that
take two PJ_OBJ. Up to now, we arbitrarily selected the context
of one of the arguments to attach it to the new object.

So better be explicit on which context is used.

For reference, in those wrappers of the C++ API, the
context is mostly used for two things:
- reporting C++ exceptions as PROJ errors with the error handler
  attached to the PJ_CONTEXT
- using the database handle that is associated with the PJ_CONTEXT.

…experimental.h header

…no match

…base when possible