Refactor moving of modal elements to solve multiple issues

[MadsBuchmann]

Which issue does this PR close?

This PR closes #2096
This PR closes #2116
This PR closes #1517

What is the new behavior?

I'm messing around with refactoring the modal to make it easier to grasp and solve a few bugs.

Before

A mutation observer was used for watching for changes in the embedded component. If a kirby-page-progress, kirby-page-title or kirby-modal-footer element was added, it would be moved to its desired spot.

The implementation of this was quite complex in my opinion and hard to grasp (And i have a suspiscion that i'm not the only one who believes this 👀)

Furthermore the bug from #2116 stems from the mutation observer not reacting when one of the aforementioned elements are added when they are wrapped in a component defined by the consumer.

To solve this we could either continue making it more complex (see the first suggested solution on #2116).. Or rethink how the moving of embedded components are done.

Resulting in ...

After

A new ModalElementsAdvertiser!

What we really want to know is: "which element is added/removed when?" such that we can move them out of the modal content and into the header/footer/where ever it belongs.

Instead of having the ModalWrapperComponent watch for changes, i've switched it around such that the embedded components announce themselves.

Each element that the modal should move registers itself using the method ModalElementsAdvertiser.registerElement on ngAfterViewInit.

This will in turn trigger an ModalElementsAdvertiser.[elementType].added$ observable, which the ModalWrapperComponent is subscribed to. The ModalWrapperComponent can then react accordingly.

It's more or less a simple pub/sub pattern.

Symmetrically there also exists a removed$ observable for when OnDestroy is triggered for a component.

It's a bit more verbose but i think it is easier to grasp ones head around as it is very clear what is executed when and has also made it possible to bundle relevant code some more.

Edit: new approach!

We inject the ModalWrapperComponent as a ModalElementsAdvertiser into the child elements that should be moved. They can then call a modalElementsAdvertiser.add[ElementName] and modalElementsAdvertiser.remove[elementName] method to register themselves in the wrapper component.

E.g. when a kirby-page-title element is added it calls modalElementsAdvertiser.addTitle on ngAfterviewInit and modalElementsAdvertiser.removeTitle on ngDestroy.

Does this PR introduce a breaking change?

• Yes
• No (hopefully)

Are there any additional context?

There's some remaining todos...

TODO:

• The collapse title functionality has decided to not work... I should fix that.
• ... Related to the above... Some tests are failing. Figure out why.
• A lot of the tests are actually integration tests. We should split it up such that this is visible.

Checklist:

The following tasks should be carried out in sequence in order to follow the process of contributing correctly.

Reminders

• Make sure you have implemented tests following the guidelines in: "The good: Test".
• Make sure you have updated the cookbook with examples and showcases (for bug fixes, enhancements & new components).

Review

• Do a self-review.
• Request that the changes are code-reviewed
• Request that the changes are UX reviewed (only necessary if your PR introduces visual changes)

When the pull request has been approved it will be automatically merged to stable via automerge.

[mictro]

Very nice result - consider for next show-and-tell 🥇

[mictro]

The modal-wrapper class has grown large (monolithic) - consider moving the handler code to a separate handler delegate class solely accessible by the modal-wrapper.

[mictro]

Nice interface which provides for a straight-forward and elegant distribution of responsibilities 👍

[mictro]

[mictro]

[mictro]

Really Nice 👍