Statement on full TLS 1.3 [RFC 8446] compliance is a slightly too strong

NEWS.md currently says:

Fully compliant implementation of RFC8446 (TLSv1.3)

According to https://github.com/openssl/openssl/issues/4449#issuecomment-748355999:

Technically we're not actually fully compliant -- we decided to continue to allow/offer (e.g.) DSA even for non-TLS-1.3 connections in order to preserve our API stability, despite there being a "MUST NOT" in the list at the end of https://tools.ietf.org/html/rfc8446#section-4.2.3 . There might be one or two other points of divergence, but that's the one I remember the most.

There can be good reason for not being fully compliant, but then one must not claim full compliance.
Otherwise potential users trusting this statement may later find out the hard way that certain aspects are not fulfilled.

Let's be fair to users and state upfront which (known) deviations exist (or at least tune down the word "fully"),
to prevent needless work by others to figure out that there are exceptions, and where they are.

BTW, a related topic is which optional features are supported.
Would be really nice to provide a list which of them are supported (to which extent) or not.
For instance, support for the "status_request" extension (for OCSP responses) is not mandatory,
and so far OpenSSL only supports the classical "OCSP stapling" of the server cert (but not of intermediate certs nor any client certs).

Start with NEWS.md and compare its TLS 1.3 compliance statement against RFC 8446 section 4.2.3 and the referenced OpenSSL issue 4449 comment. Document known deviations, or appropriately qualify the claim, and consider recording support for optional features such as status_request and OCSP stapling; done means users are not led to believe compliance is complete.