CoreData: introduce versioning of models
- CoreDataManagers have allModelVersions() which returns an array of
  models sorted by version number
- CoreDataManager reads the metadata of the db and then goes though the
  array of all model versions in reverse order until it finds one that
  is compatible -> found right model version for source
- If sourceModel != latestModel needs migration -> TODO
Library CoreData model v2
- add trackArtistName property to 'track'
This is in preparation for album artists, where [track artist] might be
different from trackArtist.
CoreData automatic migrations using inferred mapping model
- Obtain the mapping model via inferrence
- Migrate it to a temporary file ending in .migration
- Make backup of prev version
- Move temporary file to where prev version was

removeSQLFiles() helper method to remove all DB files (i.e. .sql*)
CoreData migration mapping model: add "debugPrint()" using category
- Prints all the entityMappings, propertyMappings, valueExpressions and
  so forth that are used in the mapping model
Helpful for debugging CoreData migrations!
CoreData: simple 1:1 copy custom mapping model
CoreData: simple example of a custom mapping model
- Was tested on Library v1->v2
- Starts off with the simple 1:1 copy mapping model
- Modifies track.name to be prefixed with "hi "
- Modifies track.trackArtistName to always be "hi"
- Does this with a custom migration policy class so the functions can be
  used in the NSExpression
CoreData: fix "corrupted database" error during a migration

- This was caused by not moving the "-wal" and "-shm" files around,
  along with the main sql file, during the migration process (e.g. when
  moving the temporary files to the final location)
- Created a new function moveSQLFilesFrom:to:, similar to the
  removeSQLFiles: function that handles the moving of all three in one
  go.
Merge branch 'master' into coredatamigrations
PlaylistTrack: artistName->trackArtistName, +albumArtistName (model v2)

- Playlist v2 Core Data model
- Rename artistName -> trackArtistName (to be crystal clear)
  - To do this involves deleting the old property and adding a new one
    that has the renamingIdentifier set to the previous property name
- Add albumArtistName
- Update PlaylistTrack accessors for these two new fields
  - Update the tag reading code to set trackArtistName
  - Update the cell view to use trackArtistName

NB: reading/setting albumArtistName not done yet.
LibraryTrack: use ALBUMARTIST tag

- Add trackArtistName property
- Rename setArtistByName->setAlbumArtistByName to be more clear
- Logic for reading tags:

albumArtist -> (in order of preference) ALBUMARTIST, ARTIST, ""
trackArtist -> nil (if ALBUMARTIST doesnt exist)
               nil (if ALBUMARTIST==ARTIST)
               ARTIST (otherwise)
In othe rwords, trackArtist==nil means regular boring album/track
LibraryView: enable searching trackArtistName too
CoreDataManager: introduce migrationOccurred: handler

- migrationOccurred: is called after a migration and the new migrated DB
  was opened successfully.
- Intended to be overridden by subclasses so they can do run custom DB
  tasks that need to be done after a migration
Update (from tags) all LibraryTracks after a migration

- This is needed to fill potential new attributes on existing tracks
- LibraryTrack has new "needsUpdate" boolean attribute
- migrationOccurred: on LibraryCoreDataManger sets needsUpdate = YES on
  all tracks so they are marked for an update
- Library upon init: runs updateAllTracksMarkedForUpdate: (in bkg GCD)
- updateAllTracksMarkedForUpdate: gets all tracks with needsUpdate == Y
  and tells them to updateFromFile: and then saves
- Track's updateFromFile: then sets needsUpdate = NO after success
PlaylistTrack: create updateFromFile: method to set attributes

- Just like LibraryTrack's in 6625a3b
- The constructor can now return nil, so Playlist was modified to catch
  that and abort when adding new tracks.
PlaylistTrack: read ALBUMARTIST tag and display this info in the table

- Only set it in the DB if the tag exists and is not blank
- In the Playlist track table:
  - Always use album artist if it exists for the artist
  - Append "// trackartist" if it is different from the album artist and
    the album artist exists
  - This is similar to foobar2000
Create dedicated "displayName" functions for PlaylistTrack

- These replace the logic in the PlaylistTrackCellView, so they can be
  located with the model and be used elsewhere in the code
TitlebarViewNS: use the PlaylistTrack displayNames for the titlebar
Code reorg to do with needsUpdate on LibraryTrack

This is in preparation for rolling this out to PlaylistTracks and
avoiding code duplication. In general things are now part of
ManagedObjectTrack rather than scattered all over the place

- Have needsUpdate and updateFromFile be part of ManagedObjectTrack
  - ManagedObjectTrack updateFromFile just resets the needsUpdate flag,
    so it is overridden in subclasses and called with super
- Move Library's updateAllTracksMarkedForUpdate into a class method of
  ManagedObjectTrack (updateAllTracksMarkedForUpdateIn:)
  - It now has to take a NSManagedObjectContext so it knows where to
    work
  - Works exactly the same as before and calls updateFromFile
- Move LibraryCoreDataManager's migrationOccurred code into a class
  method of ManagedObjectTrack (markAllTracksForUpdateIn:)
  - Works exactly the same as before
Extend post-migration updating to PlaylistTracks

Almost exactly the same as LibraryTracks. Notes:
- updateAllTracksMarkedForUpdateIn: is called in the background adding
  GCD thread which is normally used for adding new playlist files
  - I suppose this could block new files from being added during a
    migration, but this is probably safer
- Needed an extra tableView reloadData in the receivedSavedNotification
  as for some reason we did not have one earlier. This ensures the table
  is updated whenever there is a change that occurs from another
  playlist context (other than the main/UI thread one) being saved