Handle rustls_result more robustly #228

As seen in #227 and #195, our current approach to rustls_result is too easy to make mistakes with, and those mistakes lead to undefined behavior. We should try a different approach, either:

• Use a newtype with associated constants, as recommended in https://users.rust-lang.org/t/guarding-against-invalid-enum-values-arriving-via-ffi/33482, OR
• Use some static checking to ensure that (a) rustls_result is never a parameter of a function in the public API, and (b) rustls_result is never a return value of a callback.