Option to fix timestep interval

Rather than relying on differences in system clock time (i.e. from lastUpdateTime and time.now()), would be good to be able to fix the timestep used in the dynamics calculations to a fixed value.

This could be an either/or option, so if manually controlling, use wall time, if auto-controlled, use fixed time step.

The current method makes it good for real-time play, but being able to run a defined timestep means that it's possible to simulate the environment properly whilst not restricting solve times to be within the length of the sleep() command. Benefits of this are:

it's then possible to solve/run the environment faster which would reduce training times for ML/RL models (as if the solve time of the sim is << physical timestep, can crunch through 100s of 'physical sim' time in 1s of real wall clock time)
If the solving takes a long time, it's still possible to have inputs into the model at reasonable rates (e.g. if the algorithm takes 1s wall clock time to solve, at present it'd be limited to inputting instructions to the model at 1Hz, but if the wall clock and sim time are separated, it could still operate at 100Hz in sim time (but would obvs take much longer to run the simulation!)

steviet91 / furmulaone_source

Option to fix timestep interval #15