h3: remove dgram API in order to add support for RFC version

[LPardue]

h3: add HTTP/3 datagram RFC version

With this change, we add support for advertising the HTTP/3 datagram SETTING
value (0x33) defined in draft 11 and RFC-to-be when an h3 Connection is
configured to have datagrams enabled.

The format of the the HTTP/3 datagrams are pretty much structurally identical,
so there is not much meaningful difference between versions. Applications that
rely on HTTP/3 datagrams, such as to use CONNECT-UDP, would apply their own
semantics to these datagrams and can manage that themselves. Therefore, this
change doesn't provide fine grain control over versions.

h3: remove HTTP/3 datagram API

An HTTP/3 datagram is a series of fields carried in a QUIC DATAGRAM frame
payload. In draft 00, draft 11 and what will be the RFC there is a single field,
which is a variable-length integer.

Previously, the h3 module provided support functions that were a thin shim over
quiche's transport-layer datagram methods, which helped with the variable-length
encoding of the first field in the HTTP/3 datagram. However, in the meantime we
spun out the Octets crate, which allows applications to easily handle varints
themselves. Furthermore, changes in specifications like CONNECT-UDP mean that
applications are probably required to do additional processing of varint fields
that might exist after the first field. At this stage, the h3 datagram API
provides minimal utility and in the worst case is confusing for applications
that would use it for different purposes.

This change removes quiche::h3::send_dgram() and quiche::h3::recv_dgram()
functions. Instead applications are now responsible for serialization /
deserialization of HTTP/3 datagrams, with the recommendation being that they use
the Octets crate. This is demonstrated by related changes to the apps.

Since the Octets crate does not provide a C API itself, helper function have
been added to quiche's C API to support varint handling.