add soft-timeout

[eulerscheZahl]

In the recent contest we saw a high timeout rate, especially when the servers was busy on league opening, in the last hours of the contest and and the final rerun. This affected a lot of players even at the top of legend, so it seems to be a platform issue rather than players suddenly forgetting how to measure time. The contestant programs just get a random delay, sometimes 20 milliseconds long - and they lose the game because of it.

I understand that it's hard to prevent the server from doing any other tasks that affect program performance for contestants.
This commit is one suggestion to at least reduce the consequences of such a random delay: it lets each program run for an extra 50 milliseconds, but also checks if those extra 50ms were necessary. If they weren't, all is fine. Otherwise it counts as one strike, violating the time limit. If a bot exceeds the limit 3 times in the same match, it gets eliminated with a regular timeout exception. If even the additional 50ms don't help, the player can also get eliminated immediately.

I tested this code by including it in a game (private repository) I'm currently working on, it seems to work as intended.

If you have other suggestions like giving each player a budget for the whole game instead of per turn, I'm also open to that. This commit is just an attempt to mitigate the timeout issue with minimal changes to the SDK.

[eulerscheZahl]

Back to draft, discussing with others first.
Checking the time even when successfully reading from bot stdout certainly isn't ideal:

codingame-game-engine/runner/src/main/java/com/codingame/gameengine/runner/Agent.java

Lines 119 to 122 in 51a8756

	long current = System.nanoTime();
	if ((current - t0) > (timeout * 1_000_000l)) {
	break;
	}

And https://github.com/CodinGame/codingame-game-engine/blob/51a875604e5b736608666d49f6dde81ec191b033/runner/src/main/java/com/codingame/gameengine/runner/Agent.java#L124C21-L124C46
can be 0, even if input exists

available() is not reliable for piped input. It checks if there is data in the current process' input buffer. It has no way to check if preceding (pipe-wise) process is about to send some data.