False positive: HTTP response splitting

**Description of the false positive**

When `HttpServletResponse.setHeader` is passed untrusted user input, CodeQL always flags this as HTTP Response splitting. However, as far as I can tell, most of the popular servlet containers, like Jetty and Tomcat, both protect against this attack in their implementation. As such, quite a few of these alerts are false positives.

I'm not confident there are any `HttpServletResponse` implementations out there that don't currently guard against HTTP Response Splitting.

I think this query needs to be readdressed in the current ecosystem to ensure that it's actually valid in the current state of the world.

If it remains valid, then the list of servlet containers that are still vulnerable should be documented in the CodeQL alert. Additionally, I'd encourage the GitHub security lab team to engage in outreach to report to any servlet containers that are still not adequately protecting against this attack and get CVE's where appropriate.
```[tasklist]
### Tasks
- [ ] Determine which servlet containers are still vulnerable to HTTP Response Splitting
- [ ] List vulnerable servlet containers in the CodeQL documentation
- [ ] Engage in vulnerablilty reporting to remaining vulnerable OSS servlet containers
- [ ] Add a sanitizer for CRLF injection when the user-input flows throguh a `new File` constructor
```

Start by reviewing the CodeQL query for HTTP response splitting and compare its behavior with the Jetty and Tomcat HttpServletResponse implementations mentioned in the issue. Determine which servlet containers remain vulnerable, then assess whether documentation, a sanitizer, or vulnerability outreach is appropriate. Done means the query's validity is established and the resulting changes or follow-up actions are clearly documented.

Written by the indexing model from the issue text.