Consider handling low memory callbacks automatically

[zach-klippenstein]

Once #4 is done, we can listen for system low memory callbacks and set the flag to false for hidden screens to discard them and free up memory. This should drop things like running animations and bitmaps held by those screens' compositions. If a screen really needs to hold on to longer persistent state, it can use the (soon-to-come) UiSavedStateRegistry APIs, which I think should survive this.

[zach-klippenstein]

Two thoughts about this:

1. There's no way to register memory callbacks arbitrarily, the activity has to implement the callback interface. So we can't handle this fully automatically, we'd probably need to do something like return an object that had a trimMemory method to allow consumers to wire it up manually if they wanted. This is pretty clunky.
2. Overengineered.
   • Until compose has saved state support, we should never drop hidden screens but pass in an additional isVisible flag to drawChild to allow screens to clean up their own state when hidden.
   • Once saved state support arrives, that flag should be removed and all hidden screens should always be cleaned up immediately. This is what happens with View-based backstacks in the current UI framework, is automatic and predictable, solves issues like how to prevent hidden screens from doing things like showing dialogs.