Introduce lockfiles

[tnotheis]

Readiness checklist

• I added/updated unit tests.
• I added/updated integration tests.
• I ensured that the PR title is good enough for the changelog.
• I labeled the PR.

This PR enables lock files, which seems to be a good thing according to blog articles like https://www.meziantou.net/faster-and-safer-nuget-restore-using-source-mapping-and-lock-files.htm or https://devblogs.microsoft.com/nuget/enable-repeatable-package-restores-using-a-lock-file/.

[NikolaVetnic]

I've read through the articles given, I think it makes sense to use those flags. I will therefore approve the PR, though the problems that using these flags cause and which Timo mentioned in the daily should of course be addressed.

[Dannyps]

How did we manage the versions of the dependencies of our dependencies before this?

[daniel-almeida-konkconsulting]

I'm worried about the bloat of having so many package-lock files and how their maintenance will be carried out.
Worth noting that the 3rd highest rated issue on GitHub as of now is a request for a solution-wide package-lock file, which has an ongoing pull request (NuGet/Home#13288).

[tnotheis]

How did we manage the versions of the dependencies of our dependencies before this?

For clarification (I think I didn't mention that before): my main motivation for the lockfiles is the following advantage mentioned in the first linked blog post:

Performance: You don't need to compute the dependency graph again when restoring packages

I noticed in the past, that the package restore takes quite some time and did a quick research on how to speed it up.
While I currently don't see any improvement in performance, this is probably because I don't use it correctly yet. I will fix it and then we will see if it helps.

[tnotheis]

The pipelines are now passing. I'm not sure yet if renovate updates lockfiles. If not, there will be problems. But in that case, or in case of any other problem, I'd just revert the introduction of the lockfiles.