Avoid enabling multiple rustls backends by accident

For this, we had to:

- Make the choice(s) of backend explicit in tokio-xmpp features
- Avoid picking a backend through transitive dependencies in xmpp
  (reqwest->hyper->rustls).

In addition, we choose the default rustls backend by default and adapt
the examples so that they can cope with either situation.

tokio-xmpp/ChangeLog

@@ -25,6 +25,13 @@ XXXX-YY-ZZ RELEASER <admin@example.com>
       - `Component` is now gated behind `insecure-tcp` feature flag
       - `XMPPStream` and `XmppCodec` were removed in favour of the newly
         implemented `tokio_xmpp::xmlstream module.
+      - The `starttls-rust`, `tls-rust` and `tls-rust-ktls` feature flags do
+        not automatically enable a `rustls` crypto provider anymore. This is
+        to avoid conflict between two crypto providers and to avoid linking
+        unnecessary code. The `aws_lc_rs` crypto provider is still built by
+        default, however, applications which use `tokio_xmpp` without default
+        features will have to adapt their feature flags to explicitly enable
+        the `tls-rust-aws_lc_rs` or `tls-rust-ring` features. (!581)
     * Added:
       - Support for sending IQ requests while tracking their responses in a
         Future.