Prevent pruning of snapshots without an associated cleanup policy from borg archive

[jrabinow]

Solves #13

This PR changes the naming convention to depend on snapper cleanup policy for the snapshot. If there is any associated cleanup policy, the backup's name will start with snapborg_retentionpolicy_

Only backups whose name start with snapborg_retentionpolicy_ will be pruned, snapborg prune will ignore all others. In case this is undesired, an additional flag --ignore-nameprefix-warning-this-is-permanent exists to apply pruning to all backups in the archive.
This PR also comes with a --noconfirm flag to bypass the confirmation prompt associated with applying pruning to all snapshots.

The reasoning here is that when users manually create snapshots (-> no backup policy), it must be because the system state was of interest. It's therefore worthwhile backing up that snapshot and keeping it indefinitely - or at least until the user manually deletes it.

I'm unsure if this is compatible with your personal use case - would it be better to NOT have this behavior by default, but instead to implement this functionality as an additional field in the snapper userdata that the user can manually specify?

[enzingerm]

I'm sorry I didn't give any feedback for a long time. I like the reasoning behind this. However, wouldn't it be better to add a prefix like SNAPPER_NO_CLEANUP- to the archive names in question and keep the prune call like it is at the moment. This way, behaviour concerning existing archives would stay the same and only newly created manual snapshots would be exempted from pruning.

It would be nice to have this feature per default but one should be able to disable it (in the config). If the user would disable the feature some time in the future, only manual snapshots created afterwards (or the ones which havent been backed up already) should be concerned, and if the user would enable the feature some time later again, the same should apply. This way it can be kept relatively simple.

Let me know what you think of my suggestion and if you plan on implementing this (rebasing to v0.2) or if you don't. Thanks :)