Add support for credential backup flags

[santiagorodriguez96]

What

Add ability to access the backup_eligibility and backup_state flags in the authenticator data.

Introduces the methods PublicKeyCredential#backup_eligible? and PublicKeyCredential#backed_up? to access them.

Why

Level 3 of the draft adds this flags to the Authenticator Data: https://w3c.github.io/webauthn/#sctn-credential-backup. Those flags can be used to get information about credential's backup eligibility and current backup state. With the introduction of multi-device FIDO credentials, this information can be useful for Relying Parties. According to the documentation:

The following is a non-exhaustive list of how Relying Parties might use these flags:

• Requiring additional authenticators:

  When the BE flag is set to 0, the credential is a single-device credential and the generating authenticator will never allow the credential to be backed up.

  A single-device credential is not resilient to single device loss. Relying Parties SHOULD ensure that each user account has additional authenticators registered and/or an account recovery process in place. For example, the user could be prompted to set up an additional authenticator, such as a roaming authenticator or an authenticator that is capable of multi-device credentials.

• Upgrading a user to a password-free account:

  When the BS flag changes from 0 to 1, the authenticator is signaling that the credential is backed up and is protected from single device loss.

  The Relying Party MAY choose to prompt the user to upgrade their account security and remove their password.

• Adding an additional factor after a state change:

  When the BS flag changes from 1 to 0, the authenticator is signaling that the credential is no longer backed up, and no longer protected from single device loss. This could be the result of the user actions, such as disabling the backup service, or errors, such as issues with the backup service.

  When this transition occurs, the Relying Party SHOULD guide the user through a process to validate their other authentication factors. If the user does not have another credential for their account, they SHOULD be guided through adding an additional credential to ensure they do not lose access to their account. For example, the user could be prompted to set up an additional authenticator, such as a roaming authenticator or an authenticator that is capable of multi-device credentials.