* Code now considers startposition when checking returned records

Previously, the code would check if maxrecords was greater than the
matched records, but did not consider that the startposition might be
non-zero.  This is now addressed for different cases of startposition,
maxrecords and matched.

Code change in csw2.py only, to be tested. The code in csw3.py also
needs modified in a similar way.

* Functional test post_GetRecord-end expected XML corrected

The numberOfRecordsReturned in the expected XML for the test
default/post/GetRecords-end.xml was inconsistent with the number of
records in the expected XML.  This test failed when the code generating
the numberOfRecordsReturned attribute was updated.

Both the code and the expected XML for this test now agree and reflect
the correct value.

* csw3 code uses startposition in calculation of numberOfRecordsReturned

* numberOfRecordsReturned and nextRecord attributes good for maxRecords=0

The case where maxRecords=0 means that the nextRecord parameter should
be set to zero, to indicate that information on all records has been
returned.

* An amend to last commit, without the 'amend': fix to introduced problem
- a

* CITE test with maxRecords=0 now returns nextRecord=0

Although resultType=results, with maxRecords=0, the response should have
nextRecord=0, signifying that information on all the records have been
returned.

The expected XML for this CITE test has been modified to check against a
response with nextRecord=0 (instead of 1).

* If 'maxrecords' = 0, but matched records > 0, 'nextRecord' = 1

This is to comply with the current ETS-CSW test suite - cf.,
opengeospatial/ets-csw202#22

* Rolled back change to pycsw functionaltests to match ets

* CSW3 functionaltests dictate that nextrecord='0' for maxrecords='0'

Although the CSW2 behaviour is for nextrecord='1', because of the policy
of the ets-csw202 test suite, the CSW3 functionaltests in the pycsw repo
prescribe that nextrecord='0'.  This has been so for over a year, so I'm
not going to change the test.  The CSW2 behaviour might still be brought
into line with CSW2, as there is no reason for it not to (apart from the
assertion of the ets-csw202 test maintainer that the standard disallows
it).