add granularity to the 400 error template

[Keksoj]

For now, a request with a wrong header yields this 400 error:

curl localhost:1080/api -H "WrongHeaderWithUtf8: Střemeníčko"

<p>Request could not be parsed. Parser stopped at phase: Headers.</p>
<p>Diagnostic: A header is invalid, make sure all characters are UASCII (no UTF-8 allowed). Last valid header is: "Accept".</p>
<p>Further details:</p>
<pre>Parsed successfully:
 47 45 54 20 2f 61 70 69 20 48 54 54 50 2f 31 2e 31 0d 0a 48 6f 73 74 3a 20 6c 6f 63 61 6c 68 ..    GET /api HTTP/1.1\r\nHost: localh..
 .. 65 6e 74 3a 20 63 75 72 6c 2f 38 2e 31 30 2e 31 0d 0a 41 63 63 65 70 74 3a 20 2a 2f 2a 0d 0a    ..ent: curl/8.10.1\r\nAccept: */*\r\n
Partially parsed (valid):
 57 72 6f 6e 67 48 65 61 64 65 72 57 69 74 68 55 74 66 38 3a 20 53 74                               WrongHeaderWithUtf8: St
Invalid:
 c5 99 65 6d 65 6e c3 ad c4 8d 6b 6f 0d 0a 0d 0a                                                    řemeníčko\r\n\r\n</pre>

The details are too long to display, and the conversion of hexadecimal to utf8 may lead to XSS attacks.

It could be beneficial to split the templating of the 400 error into its constitutive parts: PARSED_SUCCESSFULLY, PARTIALLY_PARSED, INVALID,
and to leave out the display of the hexadecimal values in a human-readable form.

The same argument can be made about the 502 that displays parsing errors for the backend errors, which lack granularity (but with less XSS vulnerability).