NavigationViewItemRevokers use WeakRef this pointers

[StephenLPeters]

Rather than having navigation view track which items have revoker objects attached to them and ensure those get cleared during navigation view's destructor, we can simply have the callback object keep a weak ref to the navigation view rather than a raw pointer.

[StephenLPeters]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[StephenLPeters]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[StephenLPeters]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[StephenLPeters]

@lhecker FYI

[lhecker]

Love it! 🙂 I'm a bit concerned about the supposed memory leak mentioned in the other PR. Some users tend to leave their computer running for up to multiple weeks after all, but I can't judge how to solve that, or how important solving it is.

[DHowett]

I am also quite concerned about introducing a leak. Terminal is not structured like other applications, as it uses transient NavViews that it expects to be destroyed when the user is done with them.
Each one costs a pretty significant amount of memory (building our settings UI raises our commit by about 15 megabytes...) and being able to reclaim that would be ideal.

[lhecker]

@DHowett I might've misread the exchange between Stephen and Keith in #6797. A clarification about this new approach would be nice, since it lacks the "synchronous" cleanup that was happening before. I'm assuming there must've been a reason it was done that way... Testing for leaks in Windows Terminal will be a bit hard, since WinUI is leaking a lot of memory anyways already (~300kB every time we open the settings tab, which makes it hard to test for regressions).

[kmahone]

I believe that this should function correctly without any leaks. Stephen, can you verify in the debugger that the appropriate destructors are getting called as expected?

With this change, my expectation is that NavView will not keep any NavViewItems alive that are not its children. When a NavViewItem is no longer referenced anywhere, it should get destroyed, and as part of the destruction its event handlers should get unregistered.

[kmahone]

We went with this fix instead:
Fix issue with exception being thrown during cleanup of NavigationView. #6797