Fix double-removal Q_ASSERT in DockManagerPrivate::restoreStateFromXml

[fdarmayan]

Problem

CDockManager::restoreState() can crash with a failed assertion when the
saved state contains floating dock containers. The teardown path in
DockManagerPrivate::restoreStateFromXml() looks like:

for (int i = 0; i < FloatingWidgets.count(); ++i)
{
    CFloatingDockContainer* floatingWidget = FloatingWidgets[i];
    if (!floatingWidget) continue;
    _this->removeDockContainer(floatingWidget->dockContainer());
    floatingWidget->deleteLater();
}

removeDockContainer() is called and the floating widget is queued for
deletion. When the queued deleteLater() fires, ~CDockContainerWidget()
runs and calls removeDockContainer() on the manager a second time for
the same container. That second call trips:

Q_ASSERT(removed == 1);

inside CDockManager::removeDockContainer(), killing the application in
debug builds and silently corrupting the container list in release.

Fix

Use CDockContainerWidget::removeFromDockManager() (introduced in
544c624 "Unbind containers from DockManager to prevent accidental reuse
before deletion") instead of the manager-side removeDockContainer().
That helper clears the container's back-pointer to the manager up front,
so the subsequent destructor call becomes a no-op for the manager and
the assertion no longer fires.

floatingWidget->dockContainer()->removeFromDockManager();
floatingWidget->deleteLater();

Repro

1. Open an app that uses CDockManager with at least one floating dock
   container in the saved layout.
2. Call CDockManager::saveState() / restoreState() on that layout
   while floating widgets exist.
3. Observe the Q_ASSERT(removed == 1) failure in
   CDockManager::removeDockContainer() once deleteLater() drains.

Notes

• One-line change, no new public API.
• Behaviour-preserving: removeFromDockManager() already does the
  same list-removal work that removeDockContainer() did, just without
  the double-removal hazard.