feat/prefer-rkey

[MasterKale]

This PR loosens the default residentKey argument to "preferred". And the credProps extension is now always included to help provide clarity to RP's on whether the credential a user is registering is a resident key or not as clientExtensionResults.credProps.rk coming out of browser's startRegistration(). This requires browsers to support this extension; most evergreen browsers on most major platforms should support this sooner than later.

For some additional context, requiring resident keys in #307 is not strictly necessary for passwordless authentication via WebAuthn. So long as an authenticator can provide user presence and user verification signals then it shouldn't matter whether the credential it responds with is discoverable or not.

In addition, requiring resident keys during registration uses up very limited storage on security keys for those users who want to use them instead of, say, platform authenticators on mobile devices. Preferring the creation of resident keys (a.k.a. discoverable credentials) gives browsers and security keys a chance to work together to avoid exhausting the key's discoverable credential slots that defaulting to "required" would not.

Truthfully I can agree with some arguments that "discouraged" should be the default value here, since we're talking "passwordless defaults" and not "passkeys defaults". However the passkeys-enabled Android platform authenticator is "opt-in" and will only generate discoverable credentials when residentKey is "preferred" or "required". To default to "discouraged" would mean RPs would need to do user agent analysis of some kind to determine when the user is on Android and set "preferred"/"required" accordingly. That's...not ideal.

For later: w3c/webauthn#1822 is the issue in which it's highlighted that even "preferred" may not be enough as some security keys will opt to create discoverable credentials when they encounter"preferred".