It will also be much faster to fetch the remote entities in batches
rather than one at a time through LoadEntity.
One bonus/hazard with Multi Fetch GET is that it will get deleted entities
with `visible=false`, rather than returning a HTTP Status Code 410 (Gone).
This will be the only way that we can really do proper undeletion
(Incrementing the current version by 1 is not guaranteed to work. And
if a way is moved, fetching way/full will tell us whether the childnodes
are part of the way, but not necessarily whether they exist or not.)
We must be careful never to merge deleted entities into the real graph.
e.g, a deleted node will not have a 'loc' attribute, so code that assumes
every node must have a `loc` will be broken.
So because deleted entities are very special, the output from `loadMultiple`
should only be used for conflict resolution for now.
* don't worry about deep copying, because immutability
* don't need `attrs` parameter which is usually empty
* don't worry about resetting `v` entity version
For fills and shadows, style changes can happen only when
a new version of the feature is produced. If we include a
version number in the key, we need only call TagClasses on
the enter selection.
We cannot apply the same optimization for strokes, since
stroke style can depend on the tags of parent relations
as well.
