Read a Compose UI as a UI, and what it remembers as the UI's

[pyricau]

Stacked on #2939 — the base is create-ownership-rule-that-bit, so this diff is just the two commits
here. Third of the three things asked for in that thread: after reading an evicting cache as a cache,
this is the Compose slot table work.

The problem

On a Compose screen the explorer had nothing to say. Every image was flat under the root, and the answer
to "what is holding this bitmap" was a composition — one Object[] per window holding every remember
of every composable in it, side by side, so an image one screen remembers is held by the same array as an
image five screens away.

Three things were flattening a Compose UI, each found by asking independentPathsBelowDominator why a
LayoutNode was a child of the root, on a dump of leakcanary-app taken off an API 36
emulator:

The sample app has no Compose in it, and the images these numbers move around came from a screen added
to leakcanary-app for the measurement and deleted again, so a dump of it as it stands has the hierarchy
and not the images.

• AndroidComposeView.layoutNodes, a registry of every node of the window by semantics id, so a
  screen's node tree hangs off the view as a list.
• The modifier graph, which is bidirectional and therefore all one piece — a node points at its
  coordinator, a coordinator at its layer and at its neighbours, a layer at the layers it depends on. Three
  references reached into it from outside, each a GC root away: InputMethodManager → ViewRootImpl →
  ViewTreeObserver.mOnGlobalFocusListeners, SnapshotKt.applyObservers → Recomposer, and the layer
  dependency graph.
• The composition itself.

What this does

Hold a Compose UI's nodes and modifiers where they belong — the two mechanisms a view hierarchy
already has, for a LayoutNode: a virtual reference from a parent to each child
(LayoutNodeChildReferenceReader, bounded by the vector's size the way the view reader is bounded by
mChildrenCount), and OwnerRules saying a node belongs to its parent, the top node of a window to the
AndroidComposeView hosting it, and a Modifier$Node to the chain it is on.

Read what a composable remembers as the node's, not the composition's — SlotTableReferenceReader
reads the int[] that describes the slot array (five ints a group, bit 30 of the group info meaning the
group emitted a node into its first slot, a group's slots running to the next group's anchor) and hands
each slot out from the node whose composable is inside it.

That reader is the one that replaces an object's references rather than adding to them, which is the
thing to know before changing it. Adding works for a ViewGroup because the View[] sits under the
parent, so both paths start there. A composition's array sits under the composition, nowhere near the UI,
so an added reference would move a bitmap's dominator up to whatever dominates both. The array is still
a node holding its own bytes, still reached through the table's own field, and every element is still
reached exactly once. A table that doesn't validate — a dump caught mid-write, or Compose's newer
chunked linkbuffer.SlotTable — keeps every reference of its own and says so in the log, all or nothing
per table, since half a table read would leave objects reachable through nothing.

Measured

On that API 36 dump of leakcanary-app, the two commits together:

	Before	After
AndroidComposeView retained	2,619,473 B	10,368,941 B
its root LayoutNode retained	8,895 B	7,744,454 B

The BitmapPainters and AndroidImageBitmaps of a screen are now dominated by a LayoutNode under
AndroidComposeView → ComposeView → … → DecorView → MainActivity →
ActivityThread$ActivityClientRecord. A second dump of the same app: 12,844,587 B and 5,139,099 B.

Two honest limits, both written down in notes/dominator-tree.md: an image the UI both remembers and
draws occupies a slot in more than one group, so it lands on the composable containing both rather than on
the exact one; and the NodeCoordinators and GraphicsLayers themselves are still flat under the root, a
few hundred bytes each, their graph having no one entry worth naming as the owner.

Tests

ComposeUiReferencesTest, nine of them over one synthetic dump shaped like a Compose window — a view with
its node registry, a node tree two deep, a node left in the parent's array past the size it counts, a
chain of two modifiers with a focus listener pointing into it, a gapbuffer slot table remembering a value
against each node, and a chunked one this can't read. Including the invariant that matters for a reader
that moves edges: the tree still retains every byte of the dump and nothing reads as garbage.