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.

Closes #1107

in +towgs84 case, we use sprintf() with floating-point formatter to output
the ellipsoid parameters. For a locale with decimal separtor != dot, the
resulting string will not be parsed correctly by proj_atof(), leading to
wrong numeric result.

The fix is similar to the one done in pj_latlong_from_proj()

Note for later: if using C++, we could use a locale-independent formatting
solution to avoid such issue.