The logic related to dealing with the visible frontbuffer/compositing surface (i.e. the current SurfaceLayer + tiles) interacts with
- the readback system incl. locking API (for async etc1 compression of tabs being hidden)
- the activity state (paused vs. running)
- the window visibility

We try to do the right thing wrt ensuring renderers are hidden when it makes sense but try to minimize glitches by keeping the frontbuffer in some cases.

It was recently observed that we might not handle all transitions correctly. Also, with custom tabs and attaching to different WindowAndroids (through which the signals go) there are new sequences which are not tested and might not work as expected. Overall the logic looks very brittle.

We should revisit this and add some tests (content_unittests, i.e. we can probably do a unit test for RWHVAndroid where we mock the signals from WindowAndroid).