Implement TFA login requirement when TFA has not been set up

I agree something needs to be done to avoid locking UID 1 out of the site as described in #2371315: Remove UID 1 enforcement of TFA and allow hooks to require. In the end we're talking about replacing the 'require TFA' permission with a new permission 'bypass tfa setup', which makes total sense when rolling out TFA onto an existing site. However, just as the 'require TFA' had the unintended consequence of locking UID 1 and any user with the administrator role w/o TFA setup out of the site, in the case of the proposed new permission 'bypass tfa setup', it means that it will not be possible to lock any account that doesn't have TFA setup. In other words, once this module is enabled, UID1 (or any user with the "admin role") will have the permission to bypass TFA setup, allowing any attacker who manage to guess the password of any of those accounts to setup TFA and take over the account. Having a grace period to let people setup TFA is great, but there should be a way to lock any account that hasn't setup TFA within the grace period.

I'm wondering if instead of a user permission, we should use a multi-choice checklist, for example:
Roles allowed to bypass TFA during the login process:
[ ] authenticated user
[ ] administrator
[ ] editor

If you feel this is better as a separate feature request, then I'm happy to create it, but regardless we should be aware of the consequences of implementing the bypass feature as a user permission.

Quick nitpick on the 'bypass tfa setup' permission. If I understand this properly, we're actually not bypassing the TFA setup during login. What we're bypassing is the requirement to have already setup TFA (which is the default requirement w/o this new permission). Maybe a better permission name would be 'bypass tfa'.

Also, the way I understand the current patch is that someone with that new bypass permission could very well decide to never setup TFA on their account, and leave it open to hackers to compromise the account with just a password. Another reason why it's dangerous to automatically grant that permission to UID 1 per my previous comment.

Another side effect of the bypass permission that I'm noticing while testing the patch #1: given that authenticated users are not granted the bypass tfa permission by default, they are locked out as soon as TFA is enabled. Maybe we should grant this bypass permission to the authenticated user role to make the TFA roll out easier, or switch to my proposal in #3. Looks like we're in agreement @coltrane...

Thanks for implementing this fix Ben. Sorry I couldn't test your patch earlier. I tested 7.x-1.x and the workflow works great aside from #2481215: PHP notices when no fallback setup.

Here is the workflow I tested:
- created user with admin role
- set admin role to be a required TFA role using the new checkboxes implemented in the patch
- user was not able to log in (error message saying to contact site admin)
- removed admin role from user
- user was able to log in and set up TFA (I had given the Set up TFA for account permission to auth user role)
- user logged out
- granted admin role to user
- user was able to log in with TFA