Reimplement library on top of rustls::KernelConnection

[swlynch99]

This PR isn't quite complete yet but as I keep pushing forward with it I find that I'm basically rewriting the whole crate here. I would like to get some feedback on whether this direction is worth continuing in this direction before I finish + polish up the remaining parts of the PR.

TL;DR: Is it OK if I basically end up rewriting the whole crate here?

Here's how the code looks now:

• The core kTLS implementation is in the KTlsStreamImpl type. This is generic so that it can be shared between the different connection types but generics needed to do this are rather messy so it is hidden from the public API.
• The new stream types are KTlsClientStream, KTlsServerStream, and KTlsStream which are on top of KTlsStreamImpl and work how you would expect them to.
• Creating new connections is now done via KTlsConnector and KTlsAcceptor (similarly to how it works in tokio-rustls)

I've also made some smaller changes:

• I have split up the error types: probing supported ciphers has one, establishing a connection has another, and reading/writing from a connection has yet another (which gets wrapped in io::Error)
• I have cleaned up the code that probes for which ciphers are supported, and also added caching. I'll pull this out into its own PR before I actually submit this one.

Here's things that can no longer be supported and/or are no longer necessary:

• It will no longer be possible to create a KTlsStream from a tokio_rustls::TlsStream. TlsStream is built on top of ClientConnection/ServerConnection but creating a KernelConnection requires an unbuffered connection.
• This means that CorkStream is no longer necessary along with a few other methods.

TODOs:

• Documentation
• Figure out how externally driven connections should work here
• What extra operations should be exposed on connections?
• Remove code that has been superseded.

Fixes #59

[swlynch99]

I still have a bunch of work to do on this PR (as CI will indicate) but I do plan to keep filling it in.

[fasterthanlime]

TL;DR: Is it OK if I basically end up rewriting the whole crate here?

As far as I'm concerned, yes — I'm not actively developing it and this seems like a worthwhile direction.

[swlynch99]

Closing this in favor of #62