Support movableContentOf across protocol

[JakeWharton]

Currently, due to #1899, we crash when the detached subtree is re-added because children IDs clash. Even once that's fixed, we need to detect the fact that it's a reused node (probably with something like a removed=true boolean on the node) and upon re-insertion, walk its children and add them all to the map.

Once guest-side is fixed, we basically have the same problem host-side. It has the map leak that will cause the crash (#1900), but once that's fixed we need the same tree walk on re-attach.

It is unlikely that we will retain the host-side nodes across recompositions. If you are just moving the content in a single composition, however, we can send a new boolean in the remove op to signal that this is a detach with a future op performing re-attach via insertion. This will keep all nodes in the map, and only perform a re-parenting from the old children to the new children.

[JakeWharton]

Alright here's some observations:

• Calls to sendFrame can trigger multiple recomposition passes, with movableContentOf being one of the causes of this.
• We should not rely on onEndChanges on the applier, and instead check for changes after the initial composition and after each frame.
  • Emit all Treehouse guest changes at the end of a frame #2456
• The testing setup is not prepared to handle this and needs changed, probably first.
  • Only capture test snapshots after a frame completes #2455

Working on it!

[JakeWharton]

Plan:

• Change the protocol to eliminate range removal. All removes will be a single element.
  • Remove widgets individually in the protocol #2503
• Defer removing widgets from the map until the change list is realized, probably through a list that keeps track of removed widgets. We remove a widget from the removed widget list when it's reused. This is a rare event, so a quick list scan should be fine.
  • Defer removing guest nodes until change list is realized #2509
• Have protocol remove return an opaque token (read: change list index) which can be held by the widget. If the widget comes back through reuse in the same recomposition, use the token/index to update the original remove with detach=true.