Dynamic game speed
The game tends to freeze if there is too much to simulate. Currently, we add half a second to the time to let the game keep up in touch situations. This is not very beautiful and causes problems with animations, see #1199.
There are a number of temporary hiccups (ai planning settlement, users enters build mode, gfx are loaded). Having a delay does not mean your computer is too slow, it might be a one-time thing, but it just as well might not be. The difference lies in the frequency of hiccups.
So we need something adaptive.
Introduce steps between game speeds, for instance 4 ( 1.0, 1.2, 1.4, 1.6, 1.8, 2.0 ). There should be many of them such that changes can be done frequently without disturbing the user. If there are slight indications of problems, the game should decrease the rate in order to avoid having to work off older ticks.
If it is detected that the game kept up with the framerate, it can be increased again up to the value specified by the user.
Once it reaches the lower bound and stays there for a while (a few seconds), the actual game speed is changed to that, the user can be notified. Messagewidget message?
Hiccups can cause bigger delays, e.g. if a function runs for a second, the game has to redo this full seconds. If the delay is really too far, we can revert to stretching time, and just pretend that during that second, no actual time has passed.
At times of working off bigger loads, the game should still be as responsive as possible, which could be improved by letting fife redraw the screen when possible.
