First switch to LazyLock from OnceLock, to simplify the code.

Then concatenate the colour reset escape code instead of using
format!(), since the vast majority of those strings have more capacity
than their length it will avoid a reallocation in most cases.

This would've caught the embarrassing error made in the previous commit.

This happened when (a bit too hastily) applying suggestions from a
review.

Unlike poll_close, poll_shutdown will only kill the sending side of the
stream. This is relevant to perform a fully clean shutdown procedure in
XMPP.

This allows to detect and handle dying streams without getting stuck
forever.

Timeouts are always wrong, though, so we put the burden of choosing the
right values (mostly) on the creator of a stream.

Without the early return in XmlStream::poll_next in case of the stream
footer, the read state gets recreated and the logic at the top of that
function to actually handle stream shutdown gracefully is never
triggered.

Also that logic was incorrect; the correct behaviour is to wait for the
true EOF.

The old error message was pointing at the `FromXml` / `AsXml` invocation
and not on the field which actually caused the problem. The new error
message points exactly at the type of the affected field.

This makes the stream resets a lot safer, by preventing the forbidden
send-read-reset combination of events: the reset function on the
responder side now takes the element to send right before the reset,
enforcing a send-reset pattern.

This module provides XSO-based parsing, proper typestates and will
soon replace the proto module.

Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>

Github/Gitea/Forgejo CI not affected because it doesnt build docs yet

This is useful if, for example during stream negotiation, you want to
parse SASL elements and nothing else. It is also useful if you want to
write down an enum of all XMPP-related stream-level elements you accept
and don't want to loose your fingers typing all the SASL options.

We build syn then anyway, so we can build rxml macros, too.

You may note that I removed the `exhaustive` flag on the
DefinedCondition enum. This is because other elements in the same
namespace may occur as siblings of that enum, hence using `exhaustive`
may cause incorrect parse errors.

(If parsing attempts to process the `<text/>` child as DefinedCondition
first, DefinedCondition will return a fatal parser error if it is set as
exhaustive because no condition matches `text`.)

This declutters the main `xso` namespace. In addition, if (when) we
introduce more complex generic implementations, we might want to have
tests for these, and those can then live there, too, without making the
main `lib.rs` file gigantic (or moving the tests too far away from the
tested code).

The last users have now been converted to xso.