Fixes issue reported at
https://lists.osgeo.org/pipermail/gdal-dev/2020-February/051749.html

The generated pipeline assumes that the input coordinates for the grid transformation
were related to the non-Greenwich based datum, so we must compensate for that and
add logic to go back to Greenwich.

This is the consequence of a private email thread between me, Joel Haasdyk and
Roger Lott. I initially raised that the GDA2020 technical manual advertized the
Helmert transformation between GDA94 to GDA2020 to be a 3D one, with example of
a test point where ellipsoidal heights where modified. It appears this was intended.

The corresponding record in EPSG uses the EPSG:9607 "Coordinate Frame rotation (geog2D domain)"
method between the 2D geographic CRS of GDA94 and GDA2020. From the email exchange,
it appears that there's a lot of legacy explaining that Helmert transformations
are registered only between 2D CRS, which doesn't mean that when applied to the
corresponding 3D CRS, the change in ellipsoidal height should be discarded. Related
to that, the EPSG database, while it has methods flagged "(geog3D domain)" never uses them.

So... this changeset slightly ammends PROJ behaviour to ignore the "(geog2D domain)" flag,
but only consider the dimensionality of the source & target CRS. However, for a EPSG
transformation, those are always 2D CRS, hence introduce the use3DHelmert_ hack when
we know that ultimately the 'real' source & target CRS are 3D.

I wouldn't be surprised if in more complex pipeline the above logic would be lacking.
But it fixes at least simple transformations.

We required the 'Latitude of natural origin' parameter to be present,
but it is only a GDAL/PROJ specific thing, not a EPSG one.