Lock management repository before destructive action

We need to create a lock file before doing a destructive action (add, update, delete) and clean up in case it is already there when we try to use it.

More details:

We'll need to create a Task that creates a lock file and one that removes it again. the Task creating the lock file should also remove the lock in its undo() call

https://gitlab.archlinux.org/archlinux/repod/-/blob/e9add3c8b4d6e53f39a8e944b38c7d57d62ea9b8/repod/action/task.py#L147-286 is the abstract base class we'll do an implementation of; For implementation examples, just scroll down in that file

In https://gitlab.archlinux.org/archlinux/repod/-/blob/e9add3c8b4d6e53f39a8e944b38c7d57d62ea9b8/repod/cli/cli.py#L92 you can see how these Tasks are then chained and called.

The creation of a lock file should be the first thing in the chain usually (unless you're doing a dry-run). That also means, that we'll need to implement a basis pre-check that checks whether a lock file exists already. That works fairly similar to how the Task stuff is done, but is implemented here: https://gitlab.archlinux.org/archlinux/repod/-/blob/e9add3c8b4d6e53f39a8e944b38c7d57d62ea9b8/repod/action/check.py - Here again we have an abstract base class (Check) to implement a specific class from and then hardwire it into our Task for the lock file creation