text: Title: Alerting flyouts don't handle changing props particularly well
  Body: Some items from the original issue description have been addressed. Remaining tech debt:
  
  > our components are trying to do too many things at once (_AlertsForm_ is both the form for choosing an AlertType and wraps the behaviour for rendering after a type has been selected), and could be addressed by breaking these down into smaller, more specific, components. This should also help in long term maintenance and sustainability of our codebase.
  
  
  ### Original issue description ###
  I've encountered a range of UI bugs caused by the state between `AlertAdd` and `AlertForm` going out of sync.
  This seems to be caused by race conditions between the `useState` in these two components and is hard to reliably reproduce (I've been able to reproduce it in Uptime quite regularly due to their unique method of selecting an alertTypeId, but it isn't only there), but is definitely present.
  
  I'd recommend abandoning the show/hide approach, which is error prone, and instead going down a render/dont-reender approach which would mean we don't need to maintain state as often as we do now.
  While this is, potentially, less performant if the flyout is constantly created/destoryed, this seems unlikely as we don't expect users to regularly create/modify alerts at a high rate. This means that we might actually find this to be more performant as we would avoid instantiating these components in the first place for most users (unlike the current implementation).
  
  A couple of notes:
  
  1. I've already addressed this in that Connectors flyouts in TriggersActionsUI (we now only render these components when needed) in this PR: https://github.com/elastic/kibana/pull/82126. Making the same change in alerting would be a little harder as it's used throughout solutions - we'll have to work with them to address this.
  
  2. Some of these bugs are hidden from sight because our type checking isn't quite true to reality (for example, [this cast](https://github.com/elastic/kibana/blob/f60abf368a53a4ab285c53868d2d1dd7fb011418/x-pack/plugins/triggers_actions_ui/public/application/sections/alert_form/alert_add.tsx#L49) causes one of these state issues to be hidden). This is often because our components are trying to do too many things at once (_AlertsForm_ is both the form for choosing an AlertType and wraps the behaviour for rendering after a type has been selected), and could be addressed by breaking these down into smaller, more specific, components. This should also help in long term maintenance and sustainability of our codebase. 🎉 
  