jump before object section in players parsing in fast header parser

[Skazu]

I have found several matches in which errors occurred during the "objects" parsing, and subsequently the parser was unable to find the player-end marker.
Unfortunately, I could not solve the actual problem, but maybe you have an idea. I have checked in a recorded game and added a unit test.
However, in order to make the parsing more reliable, I have added a workaround that jumps back to the position before the objects in every case and searches for the player-end marker from there, which works in all cases, but is of course more unperformant, as a lot of data has to be loaded into the RAM.

[happyleavesaoc]

I think this is fixed in d56fc62

This rec (and some others) had \x0a as the wildcard byte in pattern match for the object start. That byte happens to be the newline \n which re does not match by default. So we didn't find the object start and the problems cascaded from there.