This attempts to address the geodtest failures noted in #819.
@sebastic can you re-run your tests?

The error number should not be reset until a new instance of "operation
..." is reached. The ignore-feature initially worked by accident since
pj_errno was not being reset when calling proj_errno_reset. This was
fixed in #808, which subsequently caused ignored tests to fail.

Fix issue #812

    
Now all of geodesic.c is covered except for 3 lines (and 2 of these are
intentionally dead code).
    
This corresponds to tag v1.49.2-c in the GeographicLib code base.

While testing polygons which encircle the globe multiple times, I
uncovered a problem where the range of the area was not reduced to the
allowed range (either [0, area0) or (-area0/2, area0/2]) correctly.
Since the documentation explicity restricted the calculation of polygon
areas to simple polygons, we'll defer fixing this for now.  (However the
intention was always to handle the area "algebraically" so that, for
example, a "bowtie" has zero area.  So I will plan on fixing this for
1.50.)

Update copyright dates + NEWS.

Implement Polygon AddEdge fix in C library (will be version 1.49.2 of C
library for proj 5.0.0).

Still to do: add tests to expand code coverage.  This will only affect
geodtest.c which is not part of the compiled library.

In pipelines including a Helmert shift, we need to run the test
through the 4D transformation interface, even though the input
coordinate system may be 2D.

This can be enforced by appending "0 0" to the 2D coordinate pair
in the accept instruction, which is sufficiently recognizable to
be considered an idiom for selecting 4D.

On return, however, (i.e. in the expect instruction), the last
dimensions will contain garbage, and this garbage will be
compared with "0 0" when computing the deviation.

This obviously leads to nonsensical results, which this commit
repairs by zeroing all dimensions *not given* in expect, before
computing the deviation.

Additionally, the test tolerance for geo/cartesian roundtrip
precision has been relaxed from picometer to nanometer level.

These tests have shown to intermittently bomb, and as the pm
level tolerance is probably a leftover from when deviation was
computed in degrees, not meter (and hence a factor of 111000
more tight than intended at its introduction) relaxing it
by a factor of 1000 makes ample sense.

Also, two new features, introduced while debugging this case
has been left in the code:

- improved reporting, for verbosity levels higher than 2

- a "skip" instruction, forcing all remaining work to be
  skipped (i.e. run until something strange happens - then stop
  to handle debugging, while avoiding additional garbage)