Check timestamp before ego motion extrapolation

If the frame timestamp is incorrect, it may lead to invalid extrapolation results.

2 faulty cases have already been met:

• the timestamp suddenly jumps to a very different value (because the dataset was reset, or because the machine was badly time synchronized). This case was mainly met with LV wrapping. This requested extrapolation time is very far from the previous frames timestamps, leading to huge (but most often false) extrapolated motion.
• the timestamps are most probably badly decoded when some lidar packets are missing. This case was met with ROS LiDAR drivers. For a strange reason, when some Lidar packets are dropped, the frame timestamp is not well updated. For example, for a 10 Hz sensor, we end up with frames at "computed" timestamps t0=0s, then t10.01s (instead of 0.1), then t20.2s (this is correct). This leads to approximately no extrapolation from frame 0 to 1. It might lead to less good localization result, but won't have a major impact. The more serious problem is when extrapolating from 1 to 2: as timestamps t0 and t1 are really close, extrapolating at t2 is really far from the "known" time range, leading to huge but erroneous ego motion estimation.

With this MR, in ego motion extrapolation step, we now check that the extrapolation ratio is not too important to avoid huge extrapolation results very far from the previously used poses. This allows to safely run on datasets corrupted by bad timestamps.