Return (entity-)type for collections

[JonnyJD]

This is part of #154.

This works fine so far, but lists of events can no yet be returned because events are not yet implemented (see #168).

Getting the type of a collection by MBID is a bit clumsy.
If the collection is not from the user that is currently authenticated we basically guess that it is of type release and request the list of releases. We will request events otherwise later.

Maybe there is a better option to find out the type, see:
http://chatlogs.musicbrainz.org/musicbrainz-devel/2015/2015-06/2015-06-10.html#T16-17-51-539040

[alastair]

👍

[JonnyJD]

Hm, finding the type still needs more work in the examle. Not part of the API, but having a working example is crucial for a) documentation b) checking of the API is "sane":

When the collection I request is public, then I can't use get_collections() to find out the type, since that itself always needs authentication. Authentication is tricky with collections. (see #155)

Additionally it might be wise to wait for #168 to complete so we can add full event collection support in this PR.

[JonnyJD]

I updated the example to reduce the complexity for checking the type (just tries /release and catchs a ResponseError. That is the best we can do in general. Depending on the application the user might actually know what type of collection it is, but I didn't want to clutter the command line interface for the example.

I also added XML tests for collections.

I will update the branch again when events are merged (and implement events for collections).

[alastair]

I don't think we should wait for #168 for this. Note that a work read endpoint has been released: http://tickets.musicbrainz.org/browse/MBS-8459 but we still need write. I wonder if we can rework the collection methods to make this easier to use.

[alastair]

I'm happy to 🚢 as-is

[JonnyJD]

Merged and added #175 for getting lists of events (blocked by #168).