allow getting more information out of errors

This library treats all error as mappable into one big enum, mapping onto the variants of rustls::Error, with some variants exploded into multiple values (like InvalidMessage) and some elided like the Vec in InappropriateMessage and InappropriateHandshakeMessage.

One place where this falls down is the General error type, where we elide the string value. That means RUSTLS_RESULT_GENERAL loses some information. But historically there weren't many paths that returned General so this wasn't a big deal.

In rustls 0.22 there's the new OtherError variant, which passes through an arbitrary error from a cryptographic backend. This has the same problem - right now we turn it into RUSTLS_RESULT_GENERAL, which loses information.

Returning an error enum (result a u32) is very handy because there is no allocation involved. The caller can discard the value without having to worry about freeing it.

However, we should consider changing the whole error structure. Instead of returning an enum, we could return a pointer to an opaque type *rustls_err. Returning a null pointer would indicate success, while returning a non-null pointer would indicate error. There would be a method on *rustls_err to extract the string value of the error, and another method to get the top-level enum variant.

This has the downside that the caller needs to free the error once they are done processing it. However, this may not be a huge burden because C error handling flows often include a goto cleanup where any non-NULL pointers that may have been allocated during the function get freed.

Start by tracing how rustls::Error, OtherError, and RUSTLS_RESULT_GENERAL are represented across the FFI boundary. Compare the current enum result with the proposed opaque rustls_err pointer, including string extraction and cleanup, and define the API behavior for preserving error information.