[Investigation] Simplify and refactor how the MR widget renders states

#high-interest-tech-debt

The following discussion from !120770 should be addressed:

I think we should come up with an idea on how to handle these state components in an issue though rather than in a merge request that is trying to use it 😅 Like there is also the state machine that could also have a preparing state right?

This issue is to discuss potential architectural decisions, which will likely need to be approached over the course of an epic / multiple issues.

Some things to consider:

• Not all of the states are based on an actual MR "status"
  • preparing - for example - is a meta-state when the MR doesn't yet have a state.
  • A new architecture should incorporate states that aren't driven by a MR state value
• When in various states, the MR widget shows multiple "sub-widgets": like mergeability, pipelines, approvals, etc.
  • Should these be flattened so the stateful logic has fewer branches, and fewer "super states" that toggle sub-states?