Valid `AudioEncoderConfig` algorithm for unsupported codecs with codec-specific steps

The algorithm that checks whether an object is a valid AudioEncoderConfig asks user agents to run possible codec-specific validation steps defined in the registrations listed in the registry. That seems wrong:

1. User agents can choose the codecs they support, it seems strange to ask them to implement validation steps for codecs they chose not to support. For example, when an application calls configure() with an invalid config for a codec that is not supported by a user agent (either because the user agent decided not to support it or because the codec was added to the registry recently), the spec still requires that the user agent know about any codec-specific extension, run possible validation steps defined in the underlying registration document, and throw a TypeError if the configuration is invalid. How can the user agent know anything about a codec it does not (want to) know anything about?
2. A registry is meant to be completed over time, even when it's stable. That's its purpose. Normative algorithms cannot set requirements over such a moving target (also see Specifications that reference registries in the W3C Process). If we expect user agents to implement extra validation steps, they should be integrated into the WebCodecs specification itself.

(Noting #861 and #826 as open issues somewhat related to this)

Start with the valid AudioEncoderConfig algorithm and the configure() processing steps, then review the codec registry requirements and related issues #861 and #826. Determine how the specification should handle codec-specific validation for unsupported codecs; the issue is done when the normative behavior is resolved and clearly reflected in the WebCodecs specification.