[11.x] Enhance malformed request handling

[jnoordsij]

(Rebased and retargetted version of #50470)

Solves #50466.

This PR aims to have better handling of malformed requests; in particular those which throw exceptions when certain methods on the request are called, like getMethod with content as described in issue mentioned above.

To Do:

• Add and/or adjust tests to verify general behavior
• Add test for behavior as specified in Missing handling of SuspiciousOperationException in RouteCollection #50466
• Decide on whether or not to broaden matching to RequestExceptionInterface
• Gather feedback on the approach of this PR

Implementation notes:

• I've broadened matching from just SuspiciousOperationException to RequestExceptionInterface, given that Symfony recommends this per documentation in this interface. This is a separate that can be removed if wanted, however it seems more accurate and should generally not make any difference for valid requests. No additional tests have been added for other possible exceptions as part of this broadening; this can be part of a follow-up issue/MR.
• Due to CompiledRouteCollection using a copy of the Request instance in the scope of the match method (due to requestWithoutTrailingSlash call), the getMethod call is never called on the 'original' request within the route handling and thus causes an exception when isMethod('HEAD') is performed in the scope of preparing the error response. This is once again caught by the exception handler and then correctly rendered on the second attempt. Albeit technically a little ugly, this is probably not worth addressing further as the outcome is correct and these types of requests should be extremly rare anyways.
• The existing Bad hostname provided message seems to be based on this line, but given that the exception also happens on incorrect method values (see test), a generic message seems to be more appropriate.