Support timeouts in clients

[timostamm]

In #591, we added support for timeouts in handlers. For better reliability, timeouts are now honored in clients as well.

For example, consider the following client call:

elizaClient.say({ sentence: "Hello" }, { timeoutMs: 2500 });

The timeout of 2.5 seconds is sent to the server in a request header (this works for the gRPC, gRPC-web, and for the Connect protocol). If the timeout is reached before the server could produce a response in time, it will send an error with Code.DeadlineExceeded instead.

But if this error does not reach the client (for example because a connection became unresponsive), the client would wait for a response well past the timeout. With this PR, the timeout is not just sent as a header, but it is also honored in the client. If no response arrives before the timeout, the client will raise an error with Code.DeadlineExceeded itself, and stop the request.

The logic is implemented in the functions runUnaryCall and runStreamingCall from @bufbuild/connect/protocol, so that Transport implementations do not have to care about this detail themselves. Transports implementations also no longer have to catch errors - runUnaryCall() and runStreamingCall() catch errors and convert them to a Connect error if necessary.

The old versions of the functions - runUnary and runStreaming from @bufbuild/connect - are now marked deprecated.

[timostamm]

The new run* functions handle abort signals and timeouts. They also trigger the abort signal if the Transport raises an error. This saves quite a bit of plumbing in Transport implementations, and seems worth the change.