Improve compliance with RFC 9112 for status line parsing

[osyoyu]

This patch improves compliance with RFC 9112 Section 4 for parsing the status-line of the HTTP response.

• Require the HTTP version to be in the format "HTTP/x.y"
  • Disallow cases like "http/1.1" (lowercase "http"), "HTTP" (missing version), "HTTP/10.23" (multidigit versions)
• Require a space between the status-code and the reason-phrase, even when the reason-phrase is empty
  • Disallow cases like "HTTP/1.1 200" (missing space after status code)
• Make clear that SP parsing operates on the lenient behavior, which allows 'HTAB, VT (%x0B), FF (%x0C), or bare CR' in addition to space

https://datatracker.ietf.org/doc/html/rfc9112#name-status-line

[osyoyu]

Regarding the lenient behavior on parsing SP: I personally don't think we need to keep this. OpenJDK java.net.http, Go net/http, undici all only accept single whitespaces, indicating status lines like HTTP/1.1\t200\rOK do not exist much in the wild.

Reference (RFC 9112 Section 4):

Although the status-line grammar rule requires that each of the component elements be separated by a single SP octet, recipients MAY instead parse on whitespace-delimited word boundaries and, aside from the line terminator, treat any form of whitespace as the SP separator while ignoring preceding or trailing whitespace; such whitespace includes one or more of the following octets: SP, HTAB, VT (%x0B), FF (%x0C), or bare CR. However, lenient parsing can result in response splitting security vulnerabilities if there are multiple recipients of the message and each has its own unique interpretation of robustness (see Section 11.1).