webauthn: workaround a security key bug on Windows 10.

Based on looking at logs, the following can happen:

  * A site sets residentKey=preferred in a create() call.
  * Chrome/Edge sees that and sets credProtect=2 by default, in case a discoverable credential is created.
  * Windows 10 has webauthn.dll version two. residentKey=preferred cannot be expressed in that version so it's mapped to rk=false.
  * credProtect=2 is passed to the security key by Windows.
  * The security key replies with credProtect=1 (bug).
  * Chrome/Edge reject that because a credProtect response that's present, but lower than requested, isn't considered valid.

This doesn't happen with Chrome on macOS because, there,
residentKey=preferred is mapped to rk=true and the credProtect issue
doesn't happen in that case with this security key.

Change-Id: I08e1a46b908ad6b60f645c0e3283bd19273ed25c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5447681
Commit-Queue: Adam Langley <agl@chromium.org>
Reviewed-by: Martin Kreichgauer <martinkr@google.com>
Cr-Commit-Position: refs/heads/main@{#1286799}