Correctly reschedule an initially non-recurring timer when a new definite period is specified

[mattrm456]

There is a bug when a timer is rescheduled and transitions from non-recurring to recurring. The bug occurs in the following sequence of operations:

1. A non-oneshot timer is created and scheduled to some deadline far in the future
2. The timer is quickly rescheduled to some near deadline and assigned a period by which it recurrs
3. The timer fires at the initial deadline but does not subsequently fire (i.e. the period is not honored)

It's possible that this bug was introduced ntcs::Chronology was revised to become implemented by ntcs::SkipList: when we update the ntcs::Chronology::DeadlineMapEntry in the skip list (rather than adding a new entry) we do not update the initial period to the new period. It's also possible this bug pre-dated that revision, however.

In any case, the current ntcs::SkipList-based implementation does not need ntcs::Chronology::DeadlineMapEntry::d_period nor d_oneShot, we can always safely access those fields from the associated ntci::Timer object itself, which are always written to a read from the same ntcs::Chronology::d_mutex.

This PR removes those fields from ntcs::Chronology::DeadlineMapEntry and uses the necessary fields directly from ntci::Timer.

[smtrfnv]

Please see my PR to your branch