function is needed for 'workaround for Trimble GPS week number rollover' patch

The Thunderbolt(fw version 3.00) will report GPS week number 936 on 30-Jul-2017 (week 1960), the Palisade (7.12) will report week number 1004 on
17-Nov-2018 (week 2027), the Acutime 2000 (2.02) will report week number 989 on 5-Aug-2018, and the Acutime Gold (1.12) will report week number 1567
after 1-Sep-2029.

* uses ntpcal_get_build_date() to adjust GPS week number

* move gpstolfp.c from libparse to libntp, add functions to: adjust week number, convert from GPS week&time-of-week to calendar time, convert from
calendar time to GPS week&time-of-week

* For devices with Thunderbolt-style packets: the reported week number, TOW, and UTC offset along with the week number of ntpd's build date are used to
calculate the day/hour/minute/second for refclock_process()
* For devices with Palisade-style packets: the reported date and time are used to calcuate a GPS week number and TOW since the week isn't contained in
packets available on port A

* tested with standard antenna using Thunderbolt, Palisade, Praecis Cf, Acutime 2000, Acutime Gold on amd64/Gentoo and sparc64/OpenBSD 6.1 (on the
sparc64 machine, a T5220, Thunderbolt offset varies from 100 to 900ms between ntpd startups with and without this patch)

* tested with GPS signal generator with +2 year and +19y5d offset in the navigation message and libntp:get_systime() using Thunderbolt, Palisade,
Acutime 2000, and Acutime Gold on: amd64 Gentoo, x86 Debian Jessie.

* a warning is logged if the receiver's adjusted week is more than 1000 weeks ahead of the build date