ServerSseMessage is #[non_exhaustive] but has no constructor, Default impl, or builder #793

Describe the bug
ServerSseMessage in transport::common::server_side_http was marked #[non_exhaustive] (as of 1.2.0/1.3.0), but no public constructor, Default implementation, or builder was added alongside it. Since the SessionManager trait requires downstream implementations to produce ServerSseMessage values in their returned streams, this makes it impossible to implement a custom SessionManager without resorting to unsafe code.

The same pattern affects several other structs (e.g. WorkerConfig, WorkerSendRequest, StreamableHttpServerConfig, ExponentialBackoff, PeerRequestOptions), though most of those already have Default or constructors. ServerSseMessage is the only one with no construction path at all.

Expected behavior
Downstream crates should be able to safely construct ServerSseMessage. At minimum, a Default derive (all fields are Option<T>) and/or named constructors for the two common patterns:

// Message with event ID and JSON-RPC content
ServerSseMessage::new(event_id, message)
// Priming event with retry hint (SEP-1699)
ServerSseMessage::priming(event_id, retry)

Additional context
Proposed PR: #794