Downgrade `uv = discouraged` requests to CTAP1/U2F to avoid user verification

Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1854089

There are cases where a request can be downgraded to CTAP1/U2F in order to avoid user verification on a CTAP2 authenticator.

Downgrading to CTAP1/U2F is only needed and possible when:

• The request does not set rk == required
  • Residency is not supported with CTAP1, and UV is always required for resident MakeCredential requests.
• The authenticator has some form of user verification configured (ie: clientPin == true || uv == true)
  • If UV is not configured or supported, then there's no need to bypass it.
• The authenticator supports CTAP1.
  • Needs #367, to avoid downgrades were they don't support it.
• The authenticator does not set alwaysUv == true
  • This disables CTAP1.
• The authenticator does not set makeCredUvNotRqd == true
  • Authenticators with makeCredUvNotRqd == true could handle the request as CTAP 2.1+.
  • Authenticators that don't are likely CTAP 2.0-only.
• The request sets uv == discouraged.
  • Chromium also does this when uv == preferred, but user verification "is possible" per #373.
• The request's most-preferred algorithm that the authenticator also supports is ES256 (ie: ES256 would be the selected algorithm if using CTAP2).
  • Chromium does it if ES256 is listed by the RP as an algorithm, which disregards the "ordered" part of `pubKeyCredParams.

Start by tracing the request downgrade and CTAP1/U2F selection paths, then review issue #367 and the authenticator capability checks. Done means requests meeting all listed conditions can downgrade to CTAP1/U2F, while resident-key, alwaysUv, unsupported-CTAP1, and other excluded cases do not.