Implement aws_tls_handler_write

[azkrishpy]

Summary

Adds a public aws_tls_handler_write API that lets callers write plaintext directly to a TLS channel handler and have it encrypted, without installing an upstream handler to feed the TLS handler. This is useful when using the TLS handler directly for arbitrary data.

AWS_IO_API int aws_tls_handler_write(
    struct aws_channel_handler *handler,
    struct aws_channel_slot *slot,
    struct aws_byte_buf *buf,
    aws_channel_on_message_write_completed_fn *on_write_completed,
    void *completion_user_data);

Approach

The implementation is a single portable function in source/tls_channel_handler.c that dispatches to the handler's existing process_write_message vtable entry — the same path used to encrypt-and-send-downstream. One implementation therefore covers all TLS backends (s2n, SecureTransport, SecureChannel) and BYO_CRYPTO, reusing the already-tested encryption path rather than duplicating per-platform logic.

Details:

• Buffers larger than a single pooled channel message are split across multiple messages.
• The on_write_completed callback is attached only to the final message, so it fires once the whole buffer has been written.
• On a process_write_message failure the handler does not take ownership of the message, so the message is released and the error is propagated.
• Requires negotiation to have completed; otherwise the backend raises AWS_IO_TLS_ERROR_NOT_NEGOTIATED.

Testing

Adds tls_channel_handler_write_test, which negotiates a real client/server TLS channel, calls aws_tls_handler_write on the client TLS handler from the event-loop thread, and asserts:

• the server receives the correctly decrypted plaintext, and
• the write completion callback fires with AWS_OP_SUCCESS.

Verified locally: clean compile (no new warnings) under both the SecureTransport and s2n configurations; the new test and the existing tls_channel_echo_and_backpressure_test both pass end-to-end against the s2n backend.