[josm-dev] Broken out jumbo patch

[Dave Hansen]

Why am I doing this?  Most of this is driven by needs of mine in the
validator plugin.  Some of it fixes bugs or other bad behavior that I
see.  Some of it is because some JOSM code is just really, really hard
to read for me.

I'd like to work to get this integrated.  Separating out the set like
this makes it easier for people to concentrate on small parts of the
code.  I'm going to continue to work to try and make this series easier
to understand, but if there are any bits that people find useful, I'd
like to get them merged sooner rather than later.  Would merging some of
the commands be harmful?  What about the boolean returns for
Command.execute()?

Again, why am I doing this?

1. ChangeCommand is bad.  Applying two to the same object causes bad
   things to happen, and this happens *all* *the* *time*.  Take an
   example where you want to append two nodes to a way.  You use 2
   change commands:

	way.nodes.add(node0);
	way.nodes.add(node1);

	way1 = new Way(way);
	way1.nodes.add(node2);
	c1 = new ChangeCommand(way, way1);

	way2 = new Way(way);
	way2.nodes.add(node3);
	c2 = new ChangeCommand(way, way2);

	c1.execute();
	c2.execute();
 
   You get a way with node0->1->2->3, right?  No. 'way' was overwritten
   with 'way2', which only ever had node0->1->3.  That c1 command
   basically got thrown away.

2. Having smart commands like "replace this node in this way at this
   place" is safe, verifiable, and easy to debug.
3. There are lots of common operations open-coded all over.  Like
   way.nodes.get(way.nodes.size()-1).  Let's just have a way.lastNode()
   function.
4. The validator plugin needs to know "which ways are using this node" a
   *LOT*.  This needs to be supported in the core to some degree, so we
   need some kind of reverse lookup mechanism.

-- Dave