Fix EventStream async streaming under hackney 4

[rvasyl]

Supersedes #80.

Problem

With hackney 4.x, ExAws.Bedrock.stream!/2 hangs indefinitely: the connection opens but no chunks are ever delivered. Two incompatibilities in EventStream:

1. hackney 4 negotiates HTTP/2 via ALPN by default, and the Bedrock endpoint accepts h2 — but hackney's h2 path delivers no async messages, so the very first receive (waiting on the status line) blocks forever. Bedrock's InvokeModelWithResponseStream is an HTTP/1.1 API (botocore has no HTTP/2 support either), and this module's Transfer-Encoding: chunked verification only exists on HTTP/1.1.
2. hackney 4 identifies async responses by the connection pid, not an Erlang reference, so the ref when is_reference(ref) clause in the body loop raises FunctionClauseError on the first read.

Separately (affects both hackney majors): the streaming path discarded caller :http_opts, so every stream ran with hackney's built-in 5s recv_timeout with no way to override it — slow model responses died mid-stream as {:closed, :timeout}. (The non-streaming path already forwards these via ExAws.Request.)

Changes

• Force HTTP/1.1 with protocols: [:http1] in the streaming hackney options.
• Match async refs with is_reference(ref) or is_pid(ref) so both hackney majors work.
• Honor caller :http_opts (recv_timeout, connect_timeout, pool) by merging them under the streaming defaults via a testable hackney_options/1 — streaming-critical keys (async: :once, protocols) can't be overridden.
• Raise ExAws.Error on {:error, reason} async messages and on unexpected message shapes instead of hanging the receive or crashing the decoder; guard the body-data clause with is_binary/1.

Testing

• mix test and mix credo --strict pass.
• Tested live against Bedrock on both the streaming and non-streaming paths, with hackney 4.0 and hackney 1.9.