example/ctap2: allow changing user_verification_req, check UV bit

[micolous]

Currently, the ctap2 example always uses uv = preferred, and can't test the other options without changing the code.

The ctap2_discoverable_creds example always uses uv = required, but that uses resident keys, which risks bricking CTAP 2.0-only authenticators¹. I haven't touched that at all.

This change adds a --uv flag to the ctap2 example, which defaults to preferred (ie: current behaviour).

While we're here, this also makes the ctap2 example check the UV bit of the authenticator's response. When uv = required, the example will now reject registration and authentication responses with the UV bit unset, like an RP needs to do.

This doesn't set the CredProtect extension or anything like that.

This makes it easy and safe to demonstrate #371, and that it'd be fixed by #370, but this PR is really an enhancement rather than a bugfix.

This also lets the ctap2 example demonstrate self-contained multi-factor authentication without requiring resident keys.

Footnotes

1. Resident keys require storage space, which is extremely limited on hardware authenticators (generally less than 10 slots with undefined size limits). CTAP 2.0 supports adding resident keys, but only CTAP 2.1 can manage and remove them individually. Therefore, the only way to remove a resident key on a CTAP 2.0-only authenticator is with a factory reset, which destroys all key material. ↩