the Bertin 1953 projection

NTv1 grid shift: fix file offset for reading of shift values in ntv1_can.dat

When investigating the format of NTv1 and comparing PROJ code with the actual
header of ntv1_can.dat, I discovered that the longitude & latitude shift values
started at offset 192, whereas PROJ assumed that the header was 176 bytes only.
This caused PROJ to use the wrong offsets values (shift of one grid sample by
longitude). So the effect was moderately visible, especially on the latitude,
but when comparing with NTv2, one can see that the longitude value after the
fix seems to closer to NTv2.

old:
echo "60.5 -100.5 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=ntv1_can.dat +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
  60.50022624  -100.50040292    0.00000000           inf

new:
echo "60.5 -100.5 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=ntv1_can.dat +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
  60.50022403  -100.50041841    0.00000000           inf

echo "60.5 -100.5 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=$HOME/proj/proj-datumgrid/north-america/ntv2_0.gsb +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
  60.50022348  -100.50041978    0.00000000           inf

old:
$ echo "80.1 -70.9 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=ntv1_can.dat +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
  80.10096789   -70.89746834    0.00000000           inf

new:
$ echo "80.1 -70.9 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=ntv1_can.dat +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
  80.10096858   -70.89749190    0.00000000           inf

$ echo "80.1 -70.9 0" | PROJ_LIB=/usr/share/proj src/cct -d 8 +proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=hgridshift +grids=$HOME/proj/proj-datumgrid/north-america/ntv2_0.gsb +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
  80.10096782   -70.89749276    0.00000000           inf

The Geographic offsets transformation adds an offset to the geographic longitude,
latitude coordinates, and an offset to the ellipsoidal height.
This method is normally only used when low accuracy is tolerated. It is documented
as coordinate operation method code 9619 (for geographic 2D) and 9660 (for
geographic 3D) in the EPSG dataset.

It can also be used to implement the method Geographic2D with Height Offsets
(code 9618) by noting that the input vertical component is a gravity-related
height and the output vertical component is the ellispoid height (dh being
the geoid undulation).

It can also be used to implement the method Vertical offset (code 9616)

It is used for example to transform:
- from the old Greek geographic 2D CRS to the newer GGRS87 CRS
- from Tokyo + JSLD69 height to WGS 84
- from Baltic 1977 height to Black Sea height

It is also useful to document the implicit zero-offset transformation
we do in pipelines such as

+proj=pipeline +step +inv +proj=longlat +ellps=A
               +step +proj=longlat +ellps=B

that can be explicited as

+proj=pipeline +step +inv +proj=longlat +ellps=A
               +step +proj=geogoffset [+dlon=0 +dlat=0 +dh=0]
               +step +proj=longlat +ellps=B

- classification
- tests
- coding style