AP_Vehicle: correct description of G_Dt

[peterbarker]

I'm quite sure this is not the correct fix for this problem - I'm creating this PR for discussion.

G_Dt should probable rightly be set from get_last_loop_time_s rather than get_loop_period_s. The former is the measured time for the last loop. The latter is memoised at vehicle startup based on the configured loop rate (SCHED_LOOP_RATE).

#13399 made us consistent across vehicles, but did move us from using the last loop period on Copter to using the configured loop period instead. It was the only vehicle which was using the last loop period.

I think the correct fix here is probably to eliminate G_Dt altogether, and have each place where it was being used changed to either use the desired loop rate (when initialising slew rates, for example), or to use actual last loop period (when updating filters, perhaps?). grep finds 74 matches for G_Dt, but some of the matches look identical-in-shape to others meaning it won't be 74 decisions to make.

[peterbarker]

G_Dt description is wrong
Filter rates don’t bother tridge
Navigation calculations do bother tridge
Nav code for copter uses += velocity *dt
Average achieved loop rate might need to be a thing
Time since last called only appropriate if there’s no memory in the algorithm 
Using a raw dt is bad when calculating navigation rates as it leads to throttle problems
EKF moved to average dt to avoid this sort of thing
We memoise a bunch of values in AP_Scheduler.h
Maybe the wrong thing to do?
Just variables that when you init the
A way in SITL of testing the case where the vehicle is not achieving the loop rate set in the parameter
Check that auto missions proceed at rate you have asked for
Some way to delay SITL / advance time
Sim_achieve_loop_rate which would make it slow down
Tridge did implement this as a quick hack
Aircraft not flying at speed which is configured
Target groundspeed doesn’t get achieved
Position controller is assuming that time is moving along as it should
We’re hitting timing issues more and more often not hitting desired loop rate
[10:36 AM] Peter Hall: Time since sensor samples your intergrating.
[10:44 AM] Peter Hall: You can force advance the hal time.
[10:45 AM] Peter Hall: We could just add a bit every loop.
[10:45 AM] Peter Hall: hal.scheduler->stop_clock(time)
Only changes average rate
Won’t do the every-4th-loopthing due to the 100Hz fusion step
Multiplier of some description?
Certain amount of flight time available
Calculate if task can be achieved
Decide it can
But then we don’t fly the groundspeed…
Changes which affect your loop rate shouldn’t change your groundspeed
Stop overtaxing your CPU…
We’ll leave this as a place-marker
We’ll move to making it a call on the scheduler to get the right number