Remove react references from core OverlayService apis

[pgayvallet]

Summary

Refactor the OverlayService to use framework agnostic MountPoint instead of react components.

• Modify OverlayService.openModal and OverlayService.openFlyout to use the new MountPoint interface introduced in Remove react references from core Notifications apis #49573 instead of direct react components usage
• Create sub-services for modals and flyouts
• Adapt existing calls to use the new toMountPoint adapter

Fixes #37894

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
  - [ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
  - [ ] This was checked for keyboard-only and screenreader accessibility

For maintainers

- [ ] This was checked for breaking API changes and was labeled appropriately
- [ ] This includes a feature addition or change that requires a release note and was labeled appropriately

Dev Docs

The core OverlayService methods are now framework agnostic and no longer accept react components as input. Please use kibana_react'stoMountPoint utility to convert a react component to a mountPoint.

For exemple:

core.overlays.openModal(<MyComponent/>)

Becomes:

core.overlays.openModal(toMountPoint(<MyComponent/>))

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[brianseeders]

retest

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 2cfde6e

[pgayvallet]

PR in standby until #49573 has been merged.

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: d64f550

[walterra]

transform/ml change LGTM

[pgayvallet]

@chandlerprall following our discussion on this PR, could you just confirm that the changes are ok for kibana-design on the react wrapper approach (at least for now)?

[pgayvallet]

#49573 has been merged, PR now integrates these changes and is ready for review

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: e26120b

[joshdover]

LGTM

[joshdover]

At some point, this stateful import will probably go away. Can we pass this Provider down from the I18n service to future-proof this a bit?

[pgayvallet]

Sure. However, the stateful import is also used in kibana_react'stoMountPoint

kibana/src/plugins/kibana_react/public/util/react_mount.tsx

Lines 22 to 40 in e04adbe

	import { I18nProvider } from '@kbn/i18n/react';
	import { MountPoint } from 'kibana/public';
	/**
	* MountPoint converter for react nodes.
	*
	* @param node to get a mount point for
	*/
	export const toMountPoint = (node: React.ReactNode): MountPoint => {
	const mount = (element: HTMLElement) => {
	ReactDOM.render(<I18nProvider>{node}</I18nProvider>, element);
	return () => ReactDOM.unmountComponentAtNode(element);
	};
	// only used for tests and snapshots serialization
	if (process.env.NODE_ENV !== 'production') {
	mount.__reactMount__ = node;
	}
	return mount;
	};

Should this be a concern?

[joshdover]

Are we going to make these APIs a bit more consistent with banners in a separate change? (eg. overlays.flyout.open)

[pgayvallet]

I did, but reverted it in e26120b following discussion with @rudolf starting at #48431 (comment) as there was no consensus. What should we do?

[chandlerprall]

Discussion has addressed @elastic/kibana-design concerns

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 0ae0157

[rudolf]

I don't think we can come up with any magic rules for how we group this and when it makes sense to introduce a third level like core.overlays.modal.* but as it stands having only one method in a namespace makes me feel like those methods are a bit lonely 😉

So @pgayvallet @joshdover and I decided we'll try to apply the following principle in deciding how we expose API's:
We will have a bias towards exposing API's as nested namespaces (e.g. core.overlays.modal.*) as this is more future-proof. But, we will only do so if we expect that there will be additional methods in that namespace in the near future. So as an example, if we expect core.overlay.modal.open to be the only modal method, we will rather collapse that into core.overlay.openModal.