Resolved known illegal PVs; substantial time management changes

[En-En-Code]

Various illegal moves previously found in printed PVs have been resolved, namely moves after a checkmate, repeating moves being followed up by non-sense, and a mix-up in Zobrist calculations caused a promoting Black rook to have the same hash as a promoting Black queen. Some changes have made to printing the PV string. First, it is done with a single printf statement, to comply with UCI better. The input is also flushed afterwards, so GUIs render it as it is created. The big changes are changes to time management. No longer will the engine get stuck in an AB search and lose to time/disconnect. It turns out that devising an alternative time management scheme was pretty difficult to even break even with what it had before. Here are the results from 360 games at 40 moves/1 minute:

Apollo 1.2.1-pv-fixes-b515f4a vs Apollo 1.2.1-master-80dc024: +137=100-123 [51.9%]
Apollo 1.2.1-pv-fixes-b515f4a playing White: +76=43-61 [54.2%]
Apollo 1.2.1-pv-fixes-b515f4a playing Black: +61=57-62 [49.7%]
Apollo 1.2.1-pv-fixes-b515f4a results:
 - Win by checkmate: 48
 - Win by adjudication: 83
 - Win by opponent's connection stalls: 3
 - Win by opponent losing on time: 3
 - Draw by 3-fold: 66
 - Draw by fifty moves rule: 19
 - Draw by insufficient mating material: 15
 - Loss by checkmate: 48
 - Loss by adjudication: 75
ELO difference: 13.5 +/- 31.3, LOS: 80.7%, DrawRatio: 27.8%

Unfortunately, my sample size leaves a lot to be desired, but I can try to get in more if need be.

[stnevans]

Good catch on the rook/queen. Same for nodeCount. I don't exactly understand:

    //What was happening previously was the engine would often be over the nodeCount,
    //and was therefore forced to search the entire remaining depth instead of quiting out.

It's been a long time since I looked at this code. The if statement I used to have for timeouts seems especially odd. Maybe it was supposed to be an or instead of an and?

[stnevans]

Thanks for the work again, changes look good!

[En-En-Code]

I think the problem was the inequality was the wrong direction. Once the engine went over the specified number of nodes in a depth, it could not leave the depth since nodes < 3000 or 7500 would always be false, problematic in, say, endgames with a lot of decision points. If it went the other direction, it wouldn't have a problem leaving the depth early enough since Apollo's time management gives it quite a bit of leeway to continue searching without risking timeout.