AP_Scripting: Fix the lua scheduling rate to be referenced from the

start of the update

This allows specifying a return value like "return update, 10" to run
at a near perfect 100Hz, where as before it would be run 10 ms after the
script had completed it's loop, which can be highly variable as the
script experiences interupts from the system, as well as needing the
script author to take responsibility for calculating the desired update
rate at the end. This was always intended to be fixed, but I pushed it
back during the initial development, however people are begining to run
scripts that have enough processing, or are rate sensitive enough that
we are now needing to start correcting this, or scripts will have to do
their best to guess the time, which will be inferior to us providing it.

As a note if you exceeded the time expected we will be rescheduling the
script immediately, thus it will have a schedule time in the past and
will be slotted in. This can't indefinetly starve other scripts as they
will still be slotted in, but if you request an update in 1 ms, but took
100ms to run we will simply slide you back into the queue 1ms after when
you started running.

libraries/AP_Scripting/lua_scripts.cpp

@@ -176,6 +176,7 @@ void lua_scripts::run_next_script(lua_State *L) {
         return;
     }
 
+    uint64_t start_time_ms = AP_HAL::millis64();
     // strip the selected script out of the list
     script_info *script = scripts;
     scripts = script->next;
@@ -225,7 +226,7 @@ void lua_scripts::run_next_script(lua_State *L) {
                    }
 
                    // types match the expectations, go ahead and reschedule
-                   script->next_run_ms = AP_HAL::millis64() + (uint64_t)luaL_checknumber(L, -1);
+                   script->next_run_ms = start_time_ms + (uint64_t)luaL_checknumber(L, -1);
                    lua_pop(L, 1);
                    int old_ref = script->lua_ref;
                    script->lua_ref = luaL_ref(L, LUA_REGISTRYINDEX);