Dependabot added

[SRFU-NN]

I have added dependabot. It should work automatically once this pull request is accepted.

Please do not finish it, we will get around 10 PRs immediately, so let's discuss how we deal with this at a meeting before we finish the PR.

The PRs that dependabot creates include the change log and commits for the updated packages, so it is a nice place to get an overview of whether anything fundamental has changed that we need to consider. While it can also help with catching security risks, it there are other tools that are better for that (e.g. CodeQL).

I have added two update tasks, pip and github-actions.

• pip scans for all updates on our immediate dependencies. I suggest most of these should just be closed, not merged, but it is nice to get a heads up for any updates we need to react on or otherwise consider. I am not sure how it works when we don't have any requirements on those packages. Perhaps we should add a minimum version? ">=1.0.0" should be safe for most packages, right? And is more restrictive than what we do now, so it shouldn't break anything that isn't already broken.
• github-actions scans for updates to github actions. We use these as part of our workflows/github actions, e.g. to check out the repo, install python, and once we get it set up, to upload new versions to pypi. I would suggest we merge these PRs by default, since there is no risk of breaking anything except our workflows by updating.

I have set the update frequency to both to monthly, meaning that new PRs are created on the first of the month. I don't think we have anything that is more urgent than that, and that allows us to go over them at a meeting if we so desire.

I have let the number of PRs be at the default. From the documentation

By default, Dependabot opens a maximum of five pull requests for version updates. Once there are five open pull requests from Dependabot, Dependabot will not open any new requests until some of those open requests are merged or closed. Use open-pull-requests-limit to change this limit. This also provides a simple way to temporarily disable version updates for a package manager.

This option has no impact on security updates, which have a separate, internal limit of ten open pull requests.

I think it is five per update task, so five for pip, and five for github-actions.

We can evaluate whether to increase this when we have some experience with the tool. If there are five new every month, we need to up it.

I have hard-coded Søren, Søren and Morten as assignees to flag us of the PRs. This should ideally be a group, but I can't get groups to work (at least not with the CLI), so it will have to be individuals at the moment. We can remove this, it isn't need to have, just nice to have.

closes #218

[dk-teknologisk-mon]

Looks reasonable and as we discussed on last meeting the configuration makes sense for now.