Rework Toast architecture

[hrach]

Current Toast architecture is not sufficient and we need to evolve it more to support our use case.
To do so, this issue describes many gradual steps to make this happen. The goal is:

• support state saving & restoration to continue showing toast after a configuration change Toast is lost with configuration change / state is not preserved #338
• support more rich toast content
• support more "slotting" approach to allow setting test tags Consider testing of Toast #554

The implementation should be the following (each own PR):

• introduce a new "OrbitIcons" enum that has generated all the "fields" for every icon; introduce an extension function that maps the enum to Painter. (modify :generator module and generate those classes)
• change the Toast implementation to take the Enum and introduce saver; introduce rememberToastState() function
• add functionality for "toast action"; rework the architecture, remove the suspending function for showing toast and expose an action listener on the ToastState; make ToastData open to allow creating custom implementations. (you can be inspired by the material's Snackbar, but they solve the action differently than we want to solve it)
• discover and consider how the rendering of Photo would work inside a Toast, we may want to have a Toast implementation that has a slot for photos, yet we don't want to introduce a dependency on the Image loading library. The toast with the photo has different metrics; consider having more slotting API for allowing a custom test tag.