Fallback agent client

[Litarnus]

Extends the AgentClient so that it can receive a fallback client in case the agent is unavailable. The fallback client is constructed through a factory to allow frameworks and other processes to set the necessary information.

[sentry]

Bug: The fixed 10ms write timeout in writePayload is likely insufficient for large payloads, causing unnecessary fallbacks to the HTTP transport even with a healthy agent.
_{Severity: MEDIUM}

Suggested Fix

Introduce a separate, more generous timeout for the payload writing operation. Alternatively, make the write timeout configurable or calculate it dynamically based on the payload size to ensure sufficient time is allocated for large data transfers without affecting the quick connection timeout.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/Agent/Transport/AgentClient.php#L149

Potential issue: The `AgentClient` uses the same 10ms timeout (`SOCKET_TIMEOUT_SECONDS`)
for both the initial socket connection and for writing the entire payload in
`writePayload`. For large payloads, such as events with attachments, or when the agent
is under load, the non-blocking write operation may require multiple iterations that
collectively take longer than 10ms. This will cause the write to fail and trigger a
fallback to the standard HTTP transport, even if the agent is healthy and capable of
receiving the data. This leads to inefficient transport usage in certain valid
scenarios.

[Litarnus]

Attachments is a good point, maybe we should have an attachment and non attachment path