don't create a new Mug when parsing control element

Instead, re-use existing mug.  The idea is that to implement composite
questions as a plugin, it will need to be able to expect that a mug seen
when parsing its data element is the same object as that seen when
parsing its control element (hence the last few refactoring commits).

This can allow the plugin to handle plugin-specific parsing details
while still letting the core store the returned mugs the normal way,
without having to know anything about how extra plugin data is stored.

To do this, changeQuestionType() needed to be changed to alter the
existing mug rather than creating a new one and replacing it, which
required eliminating the inheritance hierarchy of mug classes and
instead having only a single Mug class, which has an `options` attribute
containing all of the type-specific information, which gets updated when
the type is changed.

There's some question as to whether this is the best approach, given the
idea that immutability is better and all that.  Perhaps having the node
contain a container containing a mug, which could then get replaced,
would be better.  But given the current state of things, I think this is
fine.

To test this, I've created a form with all of the question types, saved,
reloaded, changed, saved, reloaded.

Also changed question types.
fix write error in itemset plugin

would try to write null as a string attribute in the XML when you opened
the question but didn't change the nodeset to be a valid (non-empty)
one.