Initial attempt at changing the playlist schema

[NattyNarwhal]

Initially, playlists were handled by a one-to-many relationship of playlist to track, with an index attribute for sorting. However, this had the problem of only allowing for one track instance per playlist, and a single index for sorting. This was covered up by fetching Subsonic playlists, but was still an issue in most cases, especially local playlists.

This attempts to fix it by changing it from a relation to an array; specifically an array of URLs containing the Core Data object ID URIs. This allows for having multiple entries, and makes working with it more idiomatic as opposed to the NSSet based relation approach. However, it has some trade-offs:

• We provide some wrappers around the old interfaces to simply refactoring.
• It’s stored as [URL] transformable. Not very relational, and requires explicitly opting into NSSecureUnarchiveFromDataTransformer.
• Any store migrations (including from heavyweight migrations, like this one) will require changing all the stored URLs. We do a one-time conversion for this migration, but we’ll have to do them for any future non-lightweight migrations, or you’ll get very funny error messages and issues. I had assumed that object IDs are stable, and apparently, they aren’t! 1

This does the initial conversions from NSSet to [SBTrack], as well as refactors in SBPlaylist, the parsing operation, and the playlist view controller. It also contains our first heavyweight migration, including the magic words in the Core Data mapping DSL, such as:

FUNCTION($entityPolicy, "entriesFromTracks:" , $source.tracks)

I had considered using a traditional SQL approach, where you have a many to many entity that would effectively provide a {playlist, track, order} tuple. However, I decided against it because it would create a lot of junk objects and complicate things. If it turns out to be the right decision, we can always make another migration from the URI array towards that.

Fixes GH-192.

[NattyNarwhal]

I asked people I trust around Core Data and they think it's OK; if not, we can again, do a migration to a traditional many to many approach later. Merging the Big Change.