Consider `create` and `destroy` operations to avoid re-serializing nodes on `insert`

Through considering Shopify’s use of Remote DOM, @jakearchibald proposed that we introduce create and destroy operations; create could be called the first time a new element is being attached to the tree, and destroy could be called in a FinalizationRegistry callback, once the element is no longer used by the partner.

I was initially resistant to this because a) this does not fall out naturally from the MutationObserver subclass for environments with a real DOM, and b) because it required the host to do more work, since each individual attribute/ property set on elements will arrive as a separate message in this model. However, I think this may be the better tradeoff, since situations like reordering a table view (Jake’s main example) could require a huge amount of excess information being sent over the bridge, with each table row potentially needing both a remove and insert operation.

Original proposal (includes some code showing an approach to doing this with MutationObserver) (Shopify-only)

Start with the linked original proposal and the described Shopify Remote DOM use case; the issue names no repository files or tests. Determine the create/destroy operation design and its lifecycle requirements, then document an agreed implementation scope and validation plan.