[Feature] Autosave and recovery behaviour

[XV-02]

These two concepts seem to be aligned, so I'm going to cover them under a single issue.

For cosmic-edit, especially as we support the ability to handle a number of files/projects in parallel, we should probably look to provide the ability to recover "lost" work on a system/session/application crash. If a user is juggling even a half-dozen files across a project, an event which causes cosmic-edit to die ungracefully could have a big and very frustrating impact.

Alongside that, allowing the user to assign an autosave frequency seems to be a moderately popular feature which is supported by the likes of gedit.

From a practical standpoint, I feel like the biggest difference between the two features is whether changes are written to the master version of a file automatically, or if they are only recorded in some form of dotfile for the purposes of recovery.

Given that we are already storing a history of change deltas for undo/redo, it seems as though we can probably piggyback off of that, using our history of deltas combined with the original file to perform recovery operations that are fairly up-to-date and which also potentially preserve undo/redo history across a recovery in the event of some form of uncontrolled application termination.

This would require saving those changes to a file, and that file would need to be as secure as the master file it associates with. This might also get complicated by autosave, as generally users expect their undo/redo histories to persist regardless of any interim changes during a session with a file, so we'd need to be able to mark when the last save point is in our history of deltas for recovery reasons.

If we did create some form of associated hidden file in the same directory as the primary file, we'd also need some way to clean up that secondary file. I don't think any actively developed GUI text editors - or even word processors I can think of - save undo/redo history across sessions with a document. This means that every time a document is closed by the user, we can discard the hidden file. In effect, the hidden file should only survive a user's session with the primary file if cosmic-edit dies unexpectedly.

This also means that, should a given piece of hardware become entirely unresponsive, the same filesystem loaded on another system with cosmic-edit should be able to see the primary file and its associated secondary (hidden) file and be able to recover the work. So, if your laptop runs out of battery and powers off while editing a file on a USB stick, plugging that USB stick into another system with cosmic-edit should allow you to recover the file.

This does have the obvious downside of potentially leaving unaccounted for dotfiles hanging around though, and would need some mechanism for cleaning such files up. But, it would also leave the primary file itself unencumbered and portable which I would consider an absolute must for a text-editor.

On the autosave front, there are various levels of refinement which can be applied to this feature. The first is Autosave ever [x] minutes but others, such as Autosave on loss of focus and Keep [x] autosaves can make this more robust, but also rub up against our multitasking DE design and against questions of how to maintain security across redundant saves. I'd be inclined only to support the simplest Autosave ever [x] minutes approach. Mostly, this provides some measure of protection from user errors - such as miss-clicking a save dialogue during exit - and so I would guess a simple implementation should meet the great majority of needs.

[joshuamegnauth54]

I really appreciate the level of detail! I'm currently implementing an auto save feature which is more or less finished besides some clean up. It auto saves to the main file (i.e. overwriting it) for now because I couldn't think of a good way to handle saving and reloading back up files. Further patches will improve it of course, especially as Session support is worked on.