Refactor NotificationsService to not accept React components

[streamich]

Kibana version: 8.0.0

Describe the bug: New platform accepts React components for toast notifications.

Steps to reproduce:

Expected behavior: New platform should be library agnostic.

[elasticmachine]

Pinging @elastic/kibana-platform

[streamich]

Also flyout and modal:

[streamich]

Should we discuss creating a common interface that will be used for all plugin integration points with platform UI?

Would be also great to use that for app icon instead of implementing euiIconType and icon.

[cjcenizal]

New platform should be library agnostic.

I'd like to suggest we continue to support the existing interface, but enhance it (without introducing breaking changes) to enable a similar level of control over the toast for consumers that use other frameworks or no framework at all. Here's my line of thought...

1. EUI is Elastic's solution for building the UI layer for our apps, and it's React, so realistically React is Elastic's de facto tool for building user interfaces (Kibana included). I'm not arguing this is right or ideal, but I think it's an accurate description of reality.
2. It's a critical goal that the New Platform enable plugin developers to build plugins using whatever tools, libraries, and frameworks are best for them -- this is what I understand to be the essence of the term "library agnostic". To me, "library agnostic" doesn't mean the NP can't consider other libraries whatsoever -- it just means more of a "do no harm" approach, where it won't force plugin developers to use specific tools or libraries.
3. I think the right balance is to develop interfaces that actively support 1 while being careful to respect 2. In other words, I think we should make it easy to write React plugins (since that's what all of Elastic's plugins will be written in), but possible to write non-React plugins (to maximize our inclusion of the community).

Using toast notifications as an example, I'd suggest adding additional config parameters to support arbitrary rendering to the toast's title and text areas. This way the consumer can customize those things just like React code can, but without needing React. Something like this:

toasts.add({
  onAdd: ({ title, text}) => {
    // These are just DOM nodes so you can do anything with them.
    text.appendElement(toastBody);
  }),
  onRemove: ({ title, text }) => {
    // We'll probably need to support cleanup logic as well.
  }),
});

[pgayvallet]

This and #37894 feels like the same discussion to me. Please see #37894 (comment)