Add timeout error classification

[SamRemis]

This pull request centralizes and clarifies timeout handling across the async client and transport layers by adding a transport-level error classification API and surfacing transport-detected timeouts as a dedicated ClientTimeoutError. Transports now return an ErrorInfo that indicates whether an exception represents a timeout and whether the fault is client- or server-side, and the core async client consults that information and raises ClientTimeoutError when appropriate so callers see a single, consistent exception for client-side timeouts.

ClientTransport implementations must now implement get_error_info(exception, **kwargs) and return an ErrorInfo indicating whether the exception is a timeout and whether the fault is client- or server-side. The break was required so the core async client can reliably classify transport errors and raise a single ClientTimeoutError for client-side timeouts. This information is necessary for handling errors as a part of retries.

[jonathan343]

I need to take a deeper look, but I don't think we're catching the new exception somewhere. I hacked around the CRT client to set the connect_timeout_ms to 10. The result is the SDK will keep trying to send the request indefinitely. When debugging I see the response is:

Client timeout occurred: AWS_IO_SOCKET_TIMEOUT: socket operation timed out.

Update: This might be specific to the simple retry mode not being able to handle this. I need a bit more investigation time to get a more clean answer though

[jonathan343]

I'm a bit hesitant to make this a required piece of ClientTransport. This is breaking for existing versions of smithy_http since clients don't implement this. We need to do one of the following:

• Make this optional and handle it gracefully
• Include a breaking changelog entry so we know to version bump properly in the next release

I think I prefer the first option