Refactor file models

The File models have grown a little hairy over time:

• The core.models.File model holds a reference to submission.Article objects and exposes methods to interact with the article. Could use an ArticleFile model instead (or defer this responsibilities to core.models.Galley).
• The core.models.File model exposes the vestigial attribute is_galley, should be removed and its references replaced with an instance of Galley
• Deleting a core.models.File object leaves an orphan file in the filesystem, we should either remove the file or just flag the File object as deleted
• core.models.Galley holds a key to a Article and File, while File also holds a key to Article. The two could get out of sync. Either we make Galley inherit from a File base model OR Galley holds a key to an ArticleFile but not to an Article`
• core.models.Galley has is_remote and remote_file attributes which are interdependent. The presence of a remote_file should indicate if a galley is remote (could expose a property named is_remote preserve the original interface)
• core.models.File also has is_remote and remote_url which can get out of sync with Galley. Should only exist on one of the two models.
• core.models.Galley and core.models.File expose a method to build a path for serving an article. Both are currently in use.
• core.models.File objects cannot access the file itself, unless you somehow know where the article lives in the filesystem (under articles, under journals, under plugins...). A File instance should be able to retrieve the file on its own. Ideally, we would use Django's ``FileSystemStorage` for this, as we do with other files in the codebase.
• core.models.File exposes instance methods get_file_path and get_article_path where get_file_path takes an argument article_id whilst already holding in its state an article id. This means that a file instance could serve the path to any article file, not just itself.
• core.models.File exposes an instance method named preprint_path. This should be on a different model, as not all instances of File are preprints
• core.models.FileHistory is clever but it is tightly coupled with Article model. Should work for any file

Start by mapping the relationships and references among core.models.File, core.models.Galley, core.models.FileHistory, and submission.Article. Review existing uses of Django FileSystemStorage and the path-building methods before deciding where responsibilities belong. Done means resolving the listed ownership, consistency, deletion, storage, and generic-history concerns without leaving conflicting model interfaces.