Prevent ChildView from retaining an otherwise dropped view

[as-cii]

Fixes #1748

Previously, ChildView used to hold a strong handle to the underlying view it wanted to render. That was because we wanted to prevent rendering a view that was already dropped. Retaining the view, however, has the downside of delaying the dropping of descendant views until a scene has been invalidated and re-rendered. In particular, the following could happen:

• View X could contain and render a view Y that takes focus
• View X gets dropped, note that view Y isn't dropped as part of this because the rendered element for X hasn't been dropped yet and it contains a ChildView pointing to Y
• The presenter is invalidated and the scene gets re-rendered, causing Y to get dropped
• Note that Y is still the focused element at this point, despite it not being rendered anywhere and its parent being gone.
• If we dispatched a keystroke, we would try to traverse Y's hierarchy and panic 💥

There are several solutions that I considered and discarded when exploring the space of this problem:

1. After invalidating the scene, check if there were more dropped entities before returning from MutableAppContext::flush_effects. What I don't love about this is that it might cause us to invalidate the presenter multiple times if e.g. X contains child view Y, and Y contains child view Z, etc.. I suppose it's still linear but something about the reentrancy nature of this approach feels uncanny.
2. When traversing Y's hierarchy, simply don't panic if a parent view doesn't exist. I discarded this because it feels bad to leave some fundamental state in a dirty state, as it might violate some invariant elsewhere in the code.

Ultimately, I concluded that it is a programmer error to try to render a child view without holding it with a strong handle in the parent view. And, in general, holding strong references to views in elements seems like an anti-pattern. Therefore, instead of holding a strong handle in ChildView, we will store a weak view handle and avoid laying out/painting/etc. that view if it has been dropped already, logging an error to the console. This avoids the reentrancy of solution 1) and the incorrectness of solution 2) above.

It comes at the cost of potentially passing something that will be dropped before the ChildView has a chance to render, but it seems like those cases should be pretty rare and we will catch them with the newly-added log statement.