[New Platform Migration Phase I]: break management out of kibana plugin

[lukeelmers]

Summary

The existing management app inside of the kibana plugin needs to be moved into its own dedicated management plugin that adheres to the new platform plugin structure. There is also a ui/management directory that should be moved.

Checklist for creating a new plugin

In most cases, it is recommend to break each of these steps into 3 separate PRs

• 1. Identify all public contracts exposed by the existing service, and create or update the new plugin to re-export the public contracts. This should be a non-breaking change. Plugin should:
  • Be a directory inside of src/legacy/core_plugins
  • Have a new platform-style plugin definition in typescript, with a setup method returning the public contract (see data plugin as an example). This needs to be exported from the top-level /server and/or /public directory, e.g. export foo = new Plugin.setup()
  • Be broken into logical "services", each with a service definition class (see data plugin as an example)
  • Have all static exports done from the top level plugin definition
• 2. Update all downstream modules to import from the new location. This should be done via relative imports: import { foo } from '../../../core_plugins/foo/public/setup';
• 3. Move the code from its original location to the new location

Background

Phase I ("Move") consists of consolidating (and in some cases separating) pieces of legacy code into the overall "shape" of the new platform architecture, while still remaining in the legacy world, as legacy plugins, consuming legacy services.

A module is done with Phase I when all of its code has been relocated to the appropriate plugin, with downstream imports for the module being updated to consume it from its new location.

[elasticmachine]

Pinging @elastic/kibana-app-arch

[mattkime]

closing in favor of #51539