Refactor FxA state machine to simplify transitions

[skhamis]

Now that FxiOS has the new state machine, we're able to now re-look at the state machine system as a whole and we realized we can simplify it now that we're not merging with existing systems on the consumers. My main goals were:

1. Make it easy to reason about how clients move through the FxA flows
2. Make it simple to add/modify existing states
3. Try limit any API churn (for now), and simplify the internal parts before any public-facing API changes (if any)

@bendk had to manage two state machines in android which was the reason for the initial system, but now that they've migrated fully over, the idea came that we can remove the internal state completely and move to a flat-state-machine style. It's in draft now as I think this is a strong denature and want to get thoughts on this before moving on.

Pull Request checklist

• Breaking changes: This PR follows our breaking change policy
  • This PR follows the breaking change policy:
    • This PR has no breaking API changes, or
    • There are corresponding PRs for our consumer applications that resolve the breaking changes and have been approved
• Quality: This PR builds and tests run cleanly
  • Note:
    • For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
    • If this pull request includes a breaking change, consider cutting a new release after merging.
• Tests: This PR includes thorough tests or an explanation of why it does not
• Changelog: This PR includes a changelog entry in CHANGELOG.md or an explanation of why it does not need one
  • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
• Dependencies: This PR follows our dependency management guidelines
  • Any new dependencies are accompanied by a summary of the due diligence applied in selecting them.