saved object migrations should support embeddable migrations

[rudolf]

The embeddable service would like to allow registrators to define migrations that persistor plugins should run on any embeddable state they store on behalf of the registrator.

See #67931 for a description of the problem and the terminology (note the design in the RFC wasn't implemented).

#74352 Implemented a solution to this problem, however, it required that migrations run on every version which is ineffective. For persistors to only migrate the embedded data when necessary, they need to know which migrations were added by registrators. However, new persistors can register new migrations any time during setup. So the registrator needs a way to get all migrations before migrations run, but after the setup lifecycle completes.

To enable this plugins should be able to specify a migrations function when registering their saved object type. This allows the plugin to lazily/dynamically create all the migrations they require just before the migrations run (which is one tick after the setup lifecycle).

// From:
SavedObjectType.migrations: SavedObjectMigrationMap
// To:
SavedObjectType.migrations: SavedObjectMigrationMap | () => SavedObjectMigrationMap

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[kobelb]

@mikecote I believe this is what you and I were talking about potentially needing for Alerting's saved-object migrations as well

[mikecote]

++ I think this would work perfectly for alerting as well. We have a similar use case to migrate per alert / action type which are registered on setup (#50216).