Fix score parsing for testlib.h interactive problems with non-constant scores

[Chifwin]

Currently there is problem with score parsing for IOI interactive problems created with testlib.h on Polygon, when score isn't constant and depends on quality of the solution (e.g., number of moves made). For this cases, testlib.h provides quitp function.
This function print to stderr message (in Python f-string syntax):
"points {points} {custom message} (test case {test case number})"
Current score parsing uses regex: re.compile(br'^points (\d+)$', re.M), which fails on this output because of whitespace.
As a temporary fix, users can manually print a separate line that matches the expected format, e.g.:
quitp(points, "\npoints %d\n", points);
Proposed solution: update the regex to a more flexible version that still captures the score correctly. Suggested change:
re.compile(br'^points (\d+)', re.M)

[kiritofeng]

We have a contrib module for fractional scores that mostly follows testlib conventions: https://github.com/DMOJ/judge-server/blob/master/dmoj/contrib/coci.py (although the syntax is again different from testlib).

As for allowing for a custom message that is returned to the user, we parse this by reading stdout for checkers. The checker will not read the message unless you write a custom checker (at which point you'll have 2 layers of custom checkers...)

As for the fix, I am not opposed to it, but I am concerned that a future user might not be aware that we quietly drop the custom message passed....

[Chifwin]

Thanks for your answer! Just to clarify: the custom message produced by testlib.h includes points awarded to user for a given test case, it is not intended for user itself. However, as score parsing fails, grading fails, and solution fails with internal error. Therefore, currently only way to use non-constant scoring with testlib.h is abovementioned WA.

[kiritofeng]

If the message is for the grader itself, I think this is all the more reason for it to fail with IE: this will make it clear to the problem setter that the message is not supported behaviour, and will likely not be supported in the future (whereas if it fails quietly, this could lead to some confusion).

My preference is for not failing quietly, so I am in favour of maintaining the current behaviour as the workaround doesn't seem too onerous.