Added container data type for search and browse

This PR implements a data type (soco.data_strctures.SearchResult) for search and browse results. It subclasses a tuple, so you can now do all the cool things with these search results as you can do with a tuple like iterating over them, indexing and slicing etc.

The metadata that follows a search or a browse is available as names attributes.

I have "super charged" the __getitem__ method, to allow getting the metadata (or the list of items) in the old way i.e. by indexing the object with strings like a dictionary and prints out a deprecation warning when that happens. It is ugly (being able index an object both by strings and numbers), but it means that we can keep backwards compatibility untill user have time to fix their code up.

Exampels of use:
```python
>>> s = SoCo(ip_address)
>>> artists = s.get_music_library_information('artists')
>>> type(artists)
<class 'soco.data_structures.SearchResult'>
>>> artists.search_type
'artists'
>>> artists.number_returned
100
>>> artists.total_matches
151
>>> for artist in artists:
...     if artist.title.lower() == 'metallica':
...         metallica = artist
...         break
... 
>>> metallica
<MLArtist 'Metallica' at 0x7fa2cfa71810>
>>> s.browse(metallica)
SearchResult(items=(<MLSameArtist 'All' at 0x7fa2cfa417d0>, <MLAlbum '...and Justice for All' at 0x7fa2cfa41890>, <MLAlbum 'Acoustic Metal' at 0x7fa2cfa3ee10>, <MLAlbum 'Black' at 0x7fa2cfa3edd0>, <MLAlbum 'Creeping Death' at 0x7fa2cfa3ed50>, <MLAlbum 'Death Magnetic' at 0x7fa2cfa3ed10>, <MLAlbum 'Garage Inc. (disc 1: New Recordings '98)' at 0x7fa2cfa3ec90>, <MLAlbum 'Garage Inc. (disc 2)' at 0x7fa2cfa3ec10>, <MLAlbum 'Jump In The Fire' at 0x7fa2cfa3ebd0>, <MLAlbum 'Kill 'em All' at 0x7fa2cfa3eb90>, <MLAlbum 'Live Shit, Binge And Purge Cd1' at 0x7fa2cfa3eb50>, <MLAlbum 'Live Shit, Binge And Purge Cd2' at 0x7fa2cfa3eb10>, <MLAlbum 'Live Shit, Binge And Purge Cd3' at 0x7fa2cfa3ead0>, <MLAlbum 'Load' at 0x7fa2cfa41a10>, <MLAlbum 'Master Of Puppets' at 0x7fa2cfa3ea90>, <MLAlbum 'New Skulls For The Old Ceremon' at 0x7fa2cfa3ea50>, <MLAlbum 'One (German Single)' at 0x7fa2cfa3ea10>, <MLAlbum 'Reload' at 0x7fa2cfa3e9d0>, <MLAlbum 'Ride the Lightning' at 0x7fa2cfa3e990>, <MLAlbum 'S & M Cd 1' at 0x7fa2cfa3e950>, <MLAlbum 'S & M Cd 2' at 0x7fa2cfa3e910>, <MLAlbum 'St. Anger' at 0x7fa2cfa3e8d0>, <MLAlbum 'The $9.98 Cd Garage Days' at 0x7fa2cfa3e890>, <MLAlbum 'The Complete Garage Days' at 0x7fa2cfa3e850>), search_type=browse)
```

What do you guys think?

I'll update the get_queue and music plugin code after we have done the review of this first part.
Hmm yeah. I must admit I was somewhat in doubt here.

I looked at different sources of documentation including a few official ones, since I'm preparing to give a Python introduction to some co-workers. One of the official sources definitely mentions the distinction that you make, in-homogeneous vs. homogeneous for tuple vs. list but there is also the immutable vs. mutable difference.

Since e.g. a search really only is a search if it is unchanged, then I thought it more appropriate to use an immutable type, so that if it was changed it should no longer be a search. But, on the other hand, as long as I don't overwrite any of the methods that change it, then e.g. slicing it will still return a list instead of a new Search, so yeah, it might be better to sub-class list instead.