Refactor of file handling to allow auto-rollout of thumbnail graphics changes

[kenbot]

This is built on top of #333, which should be merged before this one.

Feature: Syncing will properly rebuild thumbnails when we change how graphics are generated

• This was previously broken, because the algorithm that decided which screenshot was a titlepic failed when the image size changed. So changing to 4:3 images resulted in multiple titlepic screenshots appearing.
• When you load DoomLauncher, it should automatically fix all of the titlepics without user intervention. You can further test this by changing GameFileTile.ImageHeight to 16:9 or whatever else, and running update GameFiles set IsSyncNeeded = 1; in SQLite. It will all automatically change back next time you run DoomLauncher.
• To enable this feature, TitlePics are now their own FileType and live in their own directory. The titlepic no longer appears in the screenshots list. I believe this is better UX, because titlepics are not screenshots, and are disposable derived images, instead of irreplaceable user data.

Refactor

I have restructured the code that handles FileTypes/FileData, which was complex and untested. There is now an abstraction called IFileHandler that handles all the coordinated manipulation of files & DB records, and applies common business rules:

Layer	Contains	Responsibilities
3	DemoHandler, GameFileImageHandler, SaveGameHandler	Provides a convenient API and applies business rules specific to those things
2	IFileHandler	Atomic manipulation of linked files & DB records. Tracks derived files and original files. Adds FullFileName to returned records
1	DataSourceAdapter, System.IO.File	Low level files & records
0	DB, file system

• Almost every line of code is now tested, almost 100 new test cases
• TileImage FileData objects can now be saved to the DB, which means the choosing logic doesn't need to be repeated until the next sync. (This includes the choice of DefaultImage).
• FileType now has a IsFixedContent property, which returns true for FileType.TileImage. FileHandler uses this to guarantee that tile image files can't be deleted.
• TitlePic is a separate FileType now
• GameFileImageHandler rolls up thumbnails, screenshots, titlepics and tile images, and the logic that controls them. This gets rid of ScreenshotHandler and ThumbnailManager. It offers a greatly simplified interface to the UI, which can just call GetMainImageLarge or GetMainImageSmall. "Thumbnail", "TileImage" and "DefaultImage" are now internal concepts to GFIH, and the UI mostly does not need to worry about this.
• The SourcePortID column in Files exclusively contains actual SourcePort IDs now, and allows null. There is a new column DerivedFromFileID which is used to track which screenshot or titlepic thumbnails have been created from.
• FileManager automatically cascades deletes to derived files.
• GameFileImageHandler, DemoHandler and SaveGameHandler all use FileHandler to get work done, and do not have direct access to the DataSourceAdapter or config.
• I've added an ability for the DataSourceAdapter to return the newly created ID in inserted records. I have only applied this to GameFile, File, IWad and SourcePort, but it's easy for us to apply it to the rest too.
• I've left the BasicFileView screens mostly alone - it would have been too much work, and I think bigger changes will be needed to those screens down the track.