Better management of MFA stages and flows

**Is your feature request related to a problem? Please describe.**
This is probably too complicated for a single feature request, but am not sure how to divide it into more manageable chunks as I need to explain what I am trying to achieve for this to make sense.

#### What am I trying to achieve
I am trying to create an authentication and recovery flows that support MFA. I want them to look something like this:

1. Authentication flow:
Log in normally, then optionally present an MFA stage (or a way to setup MFA), depending on policies and/or MFA stage's not configured action.
2. Recovery flow
After email verification, allow for recovery of either a forgotten password or lost access to an MFA method (related to #4352). When recovering an MFA stage, the user will have to pass another MFA, most likely by providing a "recovery token" (static MFA token) in order to be allowed to delete or setup a new login MFA stage (depending on exact flow configuration).

#### Problems encountered during attempting to create this setup

1. MFA stages are independent and cannot be setup/chained together into a "primary"-"recovery" MFA relationship with each other. This can be partially solved by creating an MFA setup flow that forces the user to create both MFA methods. However, this is only a partial solution (see other problems)

2. All users are free to create an unlimited number of every type of MFA from their profile pages. If there is an MFA stage with a configured setup flow, then that flow is available for use to the user without an ability to impose any restrictions. Technically, restrictions can be imposed by expression policies attached to the setup flows, but I don't think this is the best solution.

3. All users can also delete MFAs from their profile settings without any ability to impose restrictions. This can be especially damaging if a user deletes their recovery MFA method without deleting their primary one and subsequently loses access to the primary MFA (related to problem 1)

4. Regardless of the purpose of the MFA setup stage, all stages of the same type show up with the same name in the MFA enrollment dropdown menu in the user settings. For example the `static` stage shows up as `Enroll -> Static Authenticatior`. There is no way to provide a custom name such as "MFA Recovery Authenticator" for instance.

5. Related to problem 1, when a MFA validator stage has its `non_configured_action` set to "configure", it does not invoke the configuration flow associated with the MFA setup stage, but rather just lets the user configure the MFA directly. This bypasses the configuration flow, making it only (easily) accessible from the user profile page.

**Describe the solution you'd like**
All problems resolved in such a way that:

1. An admin can chain MFA methods together in a primary-backup relationship and/or restrict access or otherwise enforce rules on when any MFA method can be created/deleted and what happens after that (does any other MFA need to be created/deleted as well?)

3. An admin can enforce a maximum number of setups a MFA stage can have (for example only 1 TOTP authenticator allowed per user)

5. An admin can give custom names to MFA setup stages that show up in the user settings page enroll dropdown, so that they are easy to understand by users.

7. "non_configured_action==configure" uses the MFA setup flow

**Describe alternatives you've considered**
There aren't any unless I just don't use MFA at all.

**Additional context**
N/A