Fix a serious bug in the NTPD loopfilter. Basically what happens is that

Fix a serious bug in the NTPD loopfilter.  Basically what happens is that
when the frequency error is low (e.g. like 15ppm), but an offset correction
must be made (e.g. like 3 seconds), the rstclock() call loopfilter makes
in the S_NSET state, after adjusting the system time, will reload a
clock_offset value PRIOR to the system time adjustment actually having taken
place, because rstclock() uses offset information prior to the time step, not
after, and because the kernel may slew the time step over several seconds.

The result is that clock_offset will wind up being very high (e.g. like 3
seconds) as the loopfilter enters into the S_FREQ state.  This will cause
the loopfilter to make a wildly incorrect clock_frequency calculation and
in my tests it can take ntpd and the kernel upwards of one to two DAYS to
correct for the bad calculation.

The fix is to introduce an offset settling state, S_PFREQ, which resets
the offset calculations CLOCK_MINSEC seconds after the correction was made
in order to give the next state, S_FREQ, a good basis for calculating the
frequency drift.  clock_offset will be far more reasonable when the S_FREQ
state is entered, a good clock_frequency calculation will be made, and
ntpd will lock onto the frequency is less then half an hour (instead of
24+ hours).