Didl fiddle

This is a fairly extensive re-organisation of the DIDL handling code. It does various things:

1) Bring us more into line with the DIDL-Lite spec, as adopted by Sonos.  We are pretty much there now.

2) Handles the fact that DIDL objects can have multiple URIs, embedded in a <res> element. Previously we were hardcoding the <res> element, which could cause problems.

```python
from soco import data_structures
res = data_structures.DidlResource('a%20uri', 'a:protocol:info:xx')
didl_object = data_structures.DidlMusicTrack(title='a_title',parent_id='pid',
    item_id='iid', creator='a_creator', resources=[res]) # Note that resources is a list
print data_structures.to_didl_string(didl_object)
```
will output:
```xml
<DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/"><item id="iid" parentID="pid" restricted="true"><dc:title>a_title</dc:title><res protocolInfo="a:protocol:info:xx">a%20uri</res><dc:creator>a_creator</dc:creator><upnp:class>object.item.audioItem.musicTrack</upnp:class><desc id="cdudn" nameSpace="urn:schemas-rinconnetworks-com:metadata-1-0/">RINCON_AssociatedZPUDN</desc></item></DIDL-Lite>
```

3) Handles the fact that a DIDL element can contain multiple `<item>` and `<container>` elements. Our code had various workarounds for this (such as searching through the XML for `<item>` elements, but now handling them is much easier

4) Generally simplifying the metadata interface. In theory we can now roundtrip metadata (eg get track metadata and then resubmit it later)

5) Improves error handling. `DidlCannotCreateMetadata` has been renamed `DidlMetadataError`, and we should now be able to pick up on all sorts of anomalies, and prevent creation of invalid metadata objects

There are new unit tests to accompany all this. I will work on getting the old tests modified, but for the moment, they are disabled (but still there).

The main interfaces are likely to be the `from_didl_string` and `to_didl_string` functions, which replace the old `get_ml_item`.  The first takes a string in the form `<DIDL-Lite ....><item> ... </item><item>...</item></DIDL-Lite>` and returns a *list* of `DidlObject` instances (or instances of one of the subclasses), e.g.

```python
[<DidlMusicAlbum 'Space' at 0x10cee5310>,
 <DidlMusicAlbum 'Spem in Alium' at 0x10cef9c50>,
 <DidlMusicAlbum 'Strauss, Richard: Four Last Songs & 12 O' at 0x10cee5450>]
```

So you can feed a string received from the network to the function, and get a list of metadata objects. There is no need to encode, or build XML structures first. That is all handled for you.

`to_didl_string` will do the opposite, and you can then pass the string back over the network:

```python
>>> didl = """<DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" 
    xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" 
    xmlns:r="urn:schemas-rinconnetworks-com:metadata-1-0/" 
    xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/">
					<item id="00030020_t%3a%3a1155080%3a%3ap%3a%3a8699" parentID="0006004c_p%3a%3a8699" restricted="true">
						<dc:title>Your Heart Is an Empty Room</dc:title>
						<upnp:class>object.item.audioItem.musicTrack</upnp:class>
						<desc id="cdudn" nameSpace="urn:schemas-rinconnetworks-com:metadata-1-0/">SA_RINCON2823_nathan</desc>
					</item>
				</DIDL-Lite>"""

>>> print didl.to_dict()
{u'creator': u'a_creator',
 u'item_id': u'iid',
 u'parent_id': u'pid',
 u'restricted': True,
 u'title': u'a_title'}

```
Of course, you can still create DidlObjects manually, using the normal constructor:
```python
didl_object = data_structures.DidlMusicTrack(title='a_title',parent_id='pid',
    item_id='iid', creator='a_creator')
```
or by passing a dict:
```python
  the_dict = {
            'title': 'a_title',
            'parent_id': 'pid',
            'item_id': 'iid',
            'creator': 'a_creator',
            'restricted: True}
d = data_structures.DidlObject.from_dict(the_dict)
```

 or by passing in an ElementTree Element (if you insist)

In the process, the xml module has been improved to output namespaces better (no more `nso:`, `ns1:`), and there is a function to compare XML elements sensibly, which should help us in future testing.

As always, comments welcome.

Lawrence
I completely agree with the renaming, but I'm wondering about backwards imcompatability here. Since we used to raise this exception to the user, it is not unlikely that someone is trying to catch it by the old name. I wonder if we should simply create an extra variable here with the old name that points to the new class and then warn about deprecation in the release notes for a few releases. I'm not aware of any mechanism that would allow us to give a warning at import time, of a specific object in a module. What do you think?