[Gammaray][] showed that over time we accumulate QItemSelectionModels.
It turns out that even though they are created by the Qt classes we
inherit from, those classes don't take care of deleting them itself. So
we have to manage their lifecycles ourselves.

For the CompletionView that's easy enough, a new QItemSelectionModels is
always created by `setModel()`. The QAbstractItemView docs say to keep a
reference to the old model, call `setModel()`, then delete the old one.
So that's easy enough.

There is a QHeaderView which is a child of the CompletionView though
(via QTreeView) which is a bit problematic. When we call `QTreeView.setModel()`
that calls `header.setModel()`, which creates a new selection model in
the header, but then it calls `header.setSelectionModel()`. Which
doesn't clean up the short lived selection model created by
`header.setModel()`. And there is no reference to it saved anywhere.

So we have to go hunting for it by looking at child objects. It's a bit
yuck because we have to make several assumptions about the Qt behaviour
that I can't think of many ways to verify. I wish there was some other
way to very that the child items aren't being used, but all the do when
disconnected is call `self.clear()`, which just clears the selection.

Hopefully the fact that `header.selectionModel()` returns a different
one is reassuring enough that the child objects are fine to delete.

I moved everything into a context manager simply to avoid adding the huge
block of text into the calling function. It's still 100% coupled to the
calling function.

TODO:
* fix tests?
* raise bug ticket with Qt?

Fixes: #7947

[Gammaray]: https://github.com/KDAB/GammaRay/

[Gammaray][] showed that over time we accumulate QItemSelectionModels.
It turns out that even though they are created by the Qt classes we
inherit from, those classes don't take care of deleting them itself. So
we have to manage their lifecycles ourselves.

For the CompletionView that's easy enough, a new QItemSelectionModels is
always created by `setModel()`. The QAbstractItemView docs say to keep a
reference to the old model, call `setModel()`, then delete the old one.
So that's easy enough.

There is a QHeaderView which is a child of the CompletionView though
(via QTreeView) which is a bit problematic. When we call `QTreeView.setModel()`
that calls `header.setModel()`, which creates a new selection model in
the header, but then it calls `header.setSelectionModel()`. Which
doesn't clean up the short lived selection model created by
`header.setModel()`. And there is no reference to it saved anywhere.

So we have to go hunting for it by looking at child objects. It's a bit
yuck because we have to make several assumptions about the Qt behaviour
that I can't think of many ways to verify. I wish there was some other
way to very that the child items aren't being used, but all the do when
disconnected is call `self.clear()`, which just clears the selection.

Hopefully the fact that `header.selectionModel()` returns a different
one is reassuring enough that the child objects are fine to delete.

I moved everything into a context manager simply to avoid adding the huge
block of text into the calling function. It's still 100% coupled to the
calling function.

TODO:
* fix tests?
* raise bug ticket with Qt?

Fixes: #7947

[Gammaray]: https://github.com/KDAB/GammaRay/

[Gammaray][] showed that over time we accumulate QItemSelectionModels.
It turns out that even though they are created by the Qt classes we
inherit from, those classes don't take care of deleting them itself. So
we have to manage their lifecycles ourselves.

For the CompletionView that's easy enough, a new QItemSelectionModels is
always created by `setModel()`. The QAbstractItemView docs say to keep a
reference to the old model, call `setModel()`, then delete the old one.
So that's easy enough.

There is a QHeaderView which is a child of the CompletionView though
(via QTreeView) which is a bit problematic. When we call `QTreeView.setModel()`
that calls `header.setModel()`, which creates a new selection model in
the header, but then it calls `header.setSelectionModel()`. Which
doesn't clean up the short lived selection model created by
`header.setModel()`. And there is no reference to it saved anywhere.

So we have to go hunting for it by looking at child objects. It's a bit
yuck because we have to make several assumptions about the Qt behaviour
that I can't think of many ways to verify. I wish there was some other
way to very that the child items aren't being used, but all the do when
disconnected is call `self.clear()`, which just clears the selection.

Hopefully the fact that `header.selectionModel()` returns a different
one is reassuring enough that the child objects are fine to delete.

I moved everything into a context manager simply to avoid adding the huge
block of text into the calling function. It's still 100% coupled to the
calling function.

TODO:
* more tests?
* raise bug ticket with Qt?

Fixes: #7947

[Gammaray]: https://github.com/KDAB/GammaRay/

To avoid a leak when calling `QTreeView.setModel(None)`, this commit switches
to relying on the `model.destroyed` signal to make sure related state is
cleaned up. Upstream bug: https://bugreports.qt.io/browse/QTBUG-49966

When you call `setModel(None)` on a QTreeView it causes a small memory leak
of `QItemSelectionModel` objects created by the QTreeView's child QHeaderView
object.

`QAbstractItemView` will create a new `QItemSelectionModel` whenever a model
is set, even if that model is `None`. When the new model is non-null the
new selection model will be set to be deleted when the new model is, but when
the new model is None the new selection model will be linked to the
static `QAbstractItemModelPrivate::staticEmptyModel()`. Since that empty model
lives forever, so do the related section models, unless callers take care to
clean them up themselves.

Both `QTreeView` and it's child `QHeaderView` implement `QAbstractItemView`
and have this behaviour. For the `QTreeView` we were making sure to delete
the old selection model ourselves (as of fe1215c). But for the one
created by the `QHeaderView` we can't get a reference it because
`QTreeView.setModel()` would call `QHeaderView.setModel()` and then
`QHeaderView.setSelectionModel()` right away to assign it's own
selection model to the child, leaving no references to the selection
model created by `QHeaderView.setModel()`.

I was previously using `header.findChildren(QItemSelectionModel)` to clean up
old orphaned selection models, but this approach is a lot simpler!

To observe this for yourself you can plonk something like this in
`set_model()` before the early return and switch between the old and new
implementation and see how it changes behaviour.

        header = self.header()
        header_children = header.findChildren(QItemSelectionModel)
        our_children = self.findChildren(QItemSelectionModel)
        print(f"{len(our_children)=} {len(header_children)=}")

You can also observer the selection models accumulating in Gammaray
(https://github.com/KDAB/GammaRay/) if you just open and close the selection a
lot and then filter the object view by "model".

The relevant code is in `QTreeView` and `QAbstractItemView`'s
`setModel()`, `setSlectionModel()` and `modelDestroyed()`. Bot mostly in
the `setModels()` where you can see the relevant signals being connected
and disconnected.
https://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/itemviews/qtreeview.cpp#n179

Fixes: #7947