text: Title: [Discuss][Alerting] Reorganise plugin structure
  Body: Seems we should do some clean up.
  
  # Discussion points:
  
  ## Index Threshold & ES Query builtin ruleType
  
  The Index Threshold & ES Query RuleType's UI resides in Triggers UI instead of the stackAlerts plugin. My thinking is that builtin plugins should have both a server and a public dir, as that means the UI and BE of each builtin will reside side by side.
  
  ## Which code belongs in the Alerting plugin and which in TriggersActionsUI plugin
  
  Figure out when to use an independent plugin and when to extend the alerting plugin. Currently we have two plugins `alerting` and `triggers_actions_ui`.
  
  At the moment `alerting` only has a server side plugin for the api used by consumers of the Alerting framework, while `triggers_actions_ui` has both server and public plugins, as is includes the alerts UI and the servers side code used to power that UI.
  
  With that in mind, the ViewInApp PR (https://github.com/elastic/kibana/pull/58997) introduced a `public` plugin to the `alerting` as it extends the API powering the Alerting Framework with client side navigation logic, which feels independent of the `triggers_actions_ui` (even though it is _used_ by `triggers_actions_ui`). We need to decide whether it belongs in the `triggers_actions_ui` (meaning plugins who want to use it will have to depend on both `triggers_actions_ui` and `alerting`) or whether it belongs under `alerting` (meaning plugins that want to use Alerts within their plugin only need to familiarise and rely on `alerting`).