HTTP/1 request smuggling via bare-LF, lenient chunk size, and TE/CL handling in HTTP.jl server

Summary

### Description

The HTTP/1 server request parser had three framing primitives that could make HTTP.jl disagree with a fronting proxy about message boundaries on a reused keep-alive connection. (1) `_readline_crlf` tolerated a bare `LF` on its buffered fast path but required `CRLF` on the slow path, so the accepted header grammar depended on TCP segmentation and an absorbed bare `LF` could silently merge headers. (2) `_parse_chunk_size` delegated to `Base.parse(Int64, ...; base=16)`, which tolerates a leading sign, a `0x` prefix, and whitespace padding (including a trailing bare `CR`). (3) For HTTP/1.0, `Transfer-Encoding` was stripped with a fallback to `Content-Length` while the connection could stay open, and a request carrying both `Transfer-Encoding` and `Content-Length` was silently treated as chunked.

### Impact

These parsing discrepancies enabled HTTP request smuggling past a fronting proxy on pooled/keep-alive connections.

### Patches

Fixed in HTTP.jl v2.4.0. Both line-reading paths now require a strict `CRLF` and reject a bare `LF`; chunk sizes use a strict byte-by-byte `1*HEXDIG` parser (rejecting signs, prefixes, and whitespace); HTTP/1.0 messages carrying `Transfer-Encoding` are rejected; and any request carrying both `Transfer-Encoding` and `Content-Length` is rejected. All rejections surface as a 400 with the connection force-closed so no ambiguous trailing bytes remain.

Reported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.