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.

- 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

This work mostly consists of:
- a C++ implementation of the ISO-19111:2018 / OGC Topic 2
  "Referencing by coordinates" classes to represent Datums,
  Coordinate systems, CRSs (Coordinate Reference Systems) and
  Coordinate Operations.
- methods to convert between this C++ modeling and WKT1, WKT2
  and PROJ string representations of those objects
- management and query of a SQLite3 database of CRS and Coordinate Operation definition
- a C API binding part of those capabilities

This is all-in-one squashed commit of the work of
https://github.com/OSGeo/proj.4/pull/1040