Steps to reproduce the bug:
- Drop a "Table of Content" snippet inside a page.
- Drop a "Facebook" snippet inside the "Table of Content".
-> The page is blocked.

A mechanism that interests us here is the mutation observer. Up to this
commit its goal was to regenerate the navbar of the TOC when its DOM
content changed. In practice, since [1], a "widgets_start_request"
message was triggered up each time there was a change of the TOC
content. In the case of the Facebook snippet, this behavior led to an
infinite loop. Indeed, when the Facebook snippet was dropped inside a
TOC, its content changed so a "widgets_start_request" was triggered up.
This message led to the execution of the start function of the TOC but
also of the start function of the Facebook snippet. Because there is a
change of the DOM in this last function, the mutation observer
triggered up a "widgets_start_request" message again that caused the
program to loop forever.

The goal of this commit is to regenerate the content of the navbar only
when its content changes. To do so, the content of the navbar before
the change of the DOM is compared with its content after the change of
the DOM. If those two contents are different, it means that the navbar
should be updated. Thanks to this commit, it is now possible to add
dynamic snippets such as "Facebook" or "Countdown" inside the TOC.

With this in hands, another bug appeared:
- Drop a "Table of Content" snippet inside a page.
- Drop a "Text-Image" snippet on the page but not inside the TOC.
- Drop a "Countdown" snippet inside the "Text-Image".
- Drag the entire "Text-Image" snippet with "Countdown" and drop it
inside the TOC.
-> The page is blocked.

This bug comes from the fact that the drop of a snippet that stands on
the page inside an other snippet leads to the destroy and the restart
of the option of the outer snippet. However, in our case, the mutation
observer was still listening to DOM changes even after the destroy of
the snippet option. This led to parasite function call. This bug is
fixed by disconnecting the mutation observer when the option is
destroyed. Note that this is done in this PR ([2]) as the problem
appeared in older version as well.

[1]: https://github.com/odoo/odoo/commit/a05f782871c61b2d58ca2fd4277cb7aed65a301d
[2]: https://github.com/odoo/odoo/pull/112960

task-3122249
opw-3164969
opw-3173006

Forward-Port-Of: odoo/odoo#110860