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.
Lowering the sleep time when no scripts are pending, causes starting a
REPL session to respond much faster (this cuts the latency from up to 10
seconds to 1 second before the session is ready to start).
Also lowers the default scripting debug level to hide the statustext
from users, as in the general case this is just a spammy message if it
occurs, and we should be finding better reporting bits to get this to
the user.
This helps SITL where we frequently panic about to long a statustext,
which means a user never sees the intresting part unless they comment
out the sanity check, or run on a real board.