Rework server stepping and dtime calculation

[Desour]

Old:

• game or dedicated_server_step increment server dtime counter. ServerThread
  runs in a loop in which it receives for at least 30 ms (hardcoded in Server::start()
  via m_con->SetTimeoutMs(30);), and then reads and resets the dtime counter.
  If the counter is >= 1ms, it does a server-step (AsyncRunStep).
• There are aliasing effects. E.g. in singleplayer the server-step dtimes are
  0ms (0 frames, server-step skipped), 16ms (1 frame) and 33ms (2 frames), and
  the actual times between the server-steps are >30ms or >60ms.

New:

• ServerThread receives (with timeout) until next step shall start (or longer
  if there are more packets), and calculates dtime itself.
• In singleplayer, Game tells the server if the game is paused or unfocused.

Effects:

• Shorter server dtimes are possible (i.e. <30ms).
• No dtime value aliasing.
• Server-step dtime is decoupled from client-step dtime (i.e. low client fps
  doesn't cause coarse server-steps).
  Note that pause and unfocus are now handled explicitly. But the results are
  similar to before.
• The server steps are not slower if no packets are received (fixes issue reported at Fix a very long time bug with server step when no one is moving #14093).
  (In master, the receive of the first packet has a timeout of 30 ms.)

To do

This PR is a Ready for Review.

How to test

• Try to successfully start singleplyer and dedicated server.
• Print the dtime in Server::AsyncRunStep to errorstream.

To test the #14093 issue:

• Set dedicated_server_step to 0.016.
• /lua local function f() core.sound_play("item_drop_pickup_1") core.after(0, f) end f()
  (Sound from here: https://github.com/minetest-mods/item_drop/blob/master/sounds/item_drop_pickup.1.ogg Other short sounds might work as well.)
• Alternatively, again print the dtime in Server::AsyncRunStep to errorstream.
• Notice how in master the sound plays faster (and the dtime is always about 0.016 s) when the player moves, or when you move the camera. With PR, dtime is always 16 ms.

[Desour]

(Rebased.)

[sfan5]

doesn't this mean the server step will randomly jitter from 0-999us?

[Desour]

It does. And I'd use µs precision here. But to do that, Semaphore::wait would need to be changed accordingly, and win32's WaitForSingleObject only accepts ms.

[Desour]

Rebased.

[Desour]

Rebased.
And fixed my misunderstanding of the time delta function (see commit description).

[Desour]

Trivially rebased, and comments addressed (last commit). Thx for reviewing.

[Zughy]

@Desour rebase needed

[Desour]

Rebased. And tested again. Everything works as expected.

[SmallJoker]

The server and client steps still run. Looks good.
I did not check against the time stop issue when no-one is online but given the timeout code in Server::Receive.

[lhofhansl]

Haven't had a chance to try. Looks right.