Fix #848: Weirdness in RP UP verification

§7.1. Registering a new credential currently reads (and §7.2. Verifying
an authentication assertion is analogous):

>10. If user verification is required for this registration, verify that
the User Verified bit of the `flags` in _authData_ is set.
>11. If user verification is not required for this registration, verify
that the User Present bit of the `flags` in _authData_ is set.

This results in the following truth table:

    UV req.     | UP req? | UV res. | UP res. | Accept?
    ------------+---------+---------+---------+--------
    discouraged | Yes     | 0       | 0       | No
    discouraged | Yes     | 0       | 1       | Yes
    discouraged | Yes     | 1       | 0       | No
    discouraged | Yes     | 1       | 1       | Yes
    preferred   | Yes     | 0       | 0       | No
    preferred   | Yes     | 0       | 1       | Yes
    preferred   | Yes     | 1       | 0       | No
    preferred   | Yes     | 1       | 1       | Yes
    required    | No      | 0       | 0       | No
    required    | No      | 0       | 1       | No
    required    | No      | 1       | 0       | Yes
    required    | No      | 1       | 1       | Yes

Note, for example, how UV `preferred` means that a response with `(UV=1,
UP=0)` should be rejected.

It makes more sense to let the UP requirement be defined by the UV
_response_ instead of the UV _requirement_:

    UV req.     | UV res. | UP req? | UP res. | Accept?
    ------------+---------+---------+---------+--------
    discouraged | 0       | Yes     | 0       | No
    discouraged | 0       | Yes     | 1       | Yes
    discouraged | 1       | No      | 0       | Yes
    discouraged | 1       | No      | 1       | Yes
    preferred   | 0       | Yes     | 0       | No
    preferred   | 0       | Yes     | 1       | Yes
    preferred   | 1       | No      | 0       | Yes
    preferred   | 1       | No      | 1       | Yes
    required    | 0       | Yes     | 0       | No
    required    | 0       | Yes     | 1       | No
    required    | 1       | No      | 0       | Yes
    required    | 1       | No      | 1       | Yes

index.bs

@@ -2883,8 +2883,8 @@ When registering a new credential, represented by an {{AuthenticatorAttestationR
 1. If [=user verification=] is required for this registration, verify that the [=User Verified=] bit of the <code>[=flags=]</code>
     in |authData| is set.
 
-1. If [=user verification=] is not required for this registration, verify that the [=User Present=] bit of the
-    <code>[=flags=]</code> in |authData| is set.
+1. If the [=User Verified=] bit of the <code>[=flags=]</code> in |authData| is not set, verify that the [=User Present=] bit of
+    the <code>[=flags=]</code> in |authData| is set.
 
 1. Verify that the values of the [=client extension outputs=] in |clientExtensionResults| and the [=authenticator extension
     outputs=] in the <code>[=authdataextensions|extensions=]</code> in |authData| are as expected, considering the [=client
@@ -2994,8 +2994,8 @@ When verifying a given {{PublicKeyCredential}} structure (|credential|) and an {
 1. If [=user verification=] is required for this assertion, verify that the [=User Verified=] bit of the <code>[=flags=]</code> in
     |aData| is set.
 
-1. If [=user verification=] is not required for this assertion, verify that the [=User Present=] bit of the <code>[=flags=]</code>
-    in |aData| is set.
+1. If the [=User Verified=] bit of the <code>[=flags=]</code> in |authData| is not set, verify that the [=User Present=] bit of
+    the <code>[=flags=]</code> in |authData| is set.
 
 1. Verify that the values of the [=client extension outputs=] in |clientExtensionResults| and the [=authenticator extension
     outputs=] in the <code>[=authdataextensions|extensions=]</code> in |authData| are as expected, considering the [=client