refactor!: Store node ID in TreeUpdate, not accesskit::Node

[mwcampbell]

Reasons to make this change:

• Now Node can derive Default, which makes structure initialization more standard. Note: To allow this, Role also derives Default, with a default variant of Unknown. But I really didn't want to make NodeId derive Default, since that would mean allowing a zero ID, and multiple nodes with zero IDs would be an invalid tree.
• In the persistent representation of the tree (in accesskit_consumer), the node IDs are already stored as keys in the map. So storing the IDs in the Node struct as well is redundant.
• In a future PR, I plan to do a much larger refactor, introducing a trait called something like NodeProvider that defines getter methods for all of the node fields. The accesskit::Node struct, which I will probably rename, will implement this trait, but other implementations will be encouraged, for the sake of optimization. We will have to trust these implementations to be immutable snapshots, i.e. all tree changes must be done by passing new nodes to the adapter in a TreeUpdate. Forcing the node ID to be static, i.e. outside of the future trait, will eliminate one possible way that a broken provider could break the tree.

Unfortunately, this refactor requires lots of changes to test code, but I think it's worthwhile.

[mwcampbell]

I'm abandoning this change because it increased the compiled code size, by about 12KB in a fully optimized release build of the Windows hello_world example. I think this is because I had to add the node ID to accesskit_consumer::Node, meaning the ID had to be copied into that struct in every inlined copy of node_by_id. I tried adding the ID to NodeState instead, which reverses one of the benefits listed in the first comment (because it requires a second copy of the node ID for every node in the tree), and even with that, this change increased the size of the binary by about 3KB. So I think it's not worth the trouble.

[mwcampbell]

I gave up on this too soon. I've decided that separating the node ID from the core Node struct, and the future trait with getter methods, is a better API design, even though it introduces new optimization issues. For now, I've worked around the worst of those issues by copying the node ID into NodeState, so it doesn't have to be copied into the consumer Node struct all over the place. We can do more optimization later. For now, it's important to get the API design right.

[DataTriny]

Overall I think it's going in the right direction. I think this new TreeUpdate struct will be slightly less efficient when serialization is needed though.