Bluetooth: controller: Fix assert due to stale tick count

Fixed assert due to stale tick count in role event
preparation. This happens when ticker timeout expiry is
delayed from the requested realtime anchor, due to thread
mode processing overheads and occurring interrupts therein,
if any, that added a delay between requested anchor tick
and actual scheduling for the requested ticker timeout.

The assert is reproduced in bt shell by starting advertising
and following it with continuous scanning (interval 2.5ms,
window 2.5ms), on nRF51x. If the overheads and/or a
advertiser event delayed the scheduling of scanner by over
2.5ms, then the preparation of scanner asserted.

The assert has been fixed by checking for stale tick count
at expiry in role event preparation and skip the event
gracefully.

Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>