format instead of plain old well formed XML. Note this change does not
affect the parser in any way; the parser continues to spit out its own
brand of XML, and xmlconvert treats that special when it reads it.

The XML I spit out now is better formed and makes more sense when you
look at it. It also helps that its much faster to generate, and the
resulting output is much smaller. For example:

	time /usr/testbed/libexec/xmlconvert testbed jail-2440
	real    2m54.229s
	user    1m7.492s
	sys     1m15.927s

	time /usr/testbed/devel/stoller/libexec/xmlconvert testbed jail-2440
	real    0m14.738s
	user    0m5.755s
	sys     0m5.156s

	/tmp/bar*.xml
	-rw-rw-r--  1 stoller  wheel  15595161 Jun  4 11:16 /tmp/rpc.xml
	-rw-rw-r--  1 stoller  wheel   5285690 Jun  4 11:17 /tmp/plain.xml

Thats for a big experiment. For a small experiment:

	time /usr/testbed/libexec/xmlconvert testbed jail-416
	real    0m9.346s
	user    0m5.083s
	sys     0m2.675s

	time /usr/testbed/devel/stoller/libexec/xmlconvert testbed jail-416
	real    0m2.751s
	user    0m1.377s
	sys     0m1.183s

	ll /tmp/bar*.xml
	-rw-rw-r--  1 stoller  wheel  3135518 Jun  4 11:19 /tmp/rpc.xml
	-rw-rw-r--  1 stoller  wheel  1015745 Jun  4 11:19 /tmp/plain.xml

As you can see, the RPC code is rather non-linear in its performance!

Since this affects Tim and netlab-client, I have added an alternate
XMLRPC routine called virtual_topology_xml() that returns the new format,
since Tim will need to transition to this new format (parsing it into a
Java data structure). The old format is left in the RPC server until that
is done.