This returns an iterator that yields the merged node's descendants, in
level order.

Before `Unchanged`, `Local` meant "keep local and maybe upload", and
`LocalWithNewStructure` meant "keep local and always upload". Now
that `Unchanged` exists, `Local` means "keep local and upload", so
`LocalWithNewStructure` is redundant.

Further, it wasn't obvious that `Local { remote_node: None }` meant
the item only exists locally, and should be uploaded unconditionally,
and `Remote { local_node: None }` meant the item only exists remotely,
and should be applied unconditionally. This commit changes `Local`
and `Remote` to mean "exists on both sides, but prefer one", and adds
`LocalOnly`, `RemoteOnly`, and `RemoteOnlyWithNewStructure` to mean
"exists on one side, so take unconditionally".

To that end, this commit treats remotely changed user content roots as
`Unchanged`. As of bug 1432614, roots don't have user-editable titles,
so applying remote title changes is unnecessary. However, we also don't
mark the roots as `Local`, because that would mean we'd reupload the
root _every time_ it was changed remotely.

Finally, we want callers to easily determine whether to apply remote
changes, and upload local and new changes. This commit adds
`MergeState::{should_apply, should_upload}()` for that.

This ports the merger parts of
https://bugzilla.mozilla.org/show_bug.cgi?id=1515784.

For mismatched kinds, we keep both nodes with new GUIDs. This is an
edge case: Places maintenance on Desktop can change an item's
kind without changing its GUID, but this should be rare.

In general, we can't meaningfully pick a side when two items have
different kinds (a bookmark and a folder with children? a bookmark and
a separator?), so we keep both, with new structure, to avoid possible
data loss.

See #13.