deps: use upstream qtkeychain

[Nerixyz]

Nothing requires us to use the forked version, so let's use the upstream version. That one has too many warnings on clang-cl but that's not a compiler we officially support.

[pajlada]

Swap to our forks' master branch instead, and next release we can swap repo url

[Nerixyz]

Swap to our forks' master branch instead, and next release we can swap repo url

...why? Both branches are at the same commit. If we use the upstream version, we get updates through dependabot (assuming it's not disabled).

[pajlada]

Swap to our forks' master branch instead, and next release we can swap repo url

...why? Both branches are at the same commit. If we use the upstream version, we get updates through dependabot (assuming it's not disabled).

Changing remote throws off build systems that don't use git submodules directly, instead relying on user-input submodules. If possible I like to make those changes together with, or after, a release

[Nerixyz]

Changing remote throws off build systems that don't use git submodules directly, instead relying on user-input submodules. If possible I like to make those changes together with, or after, a release

How would that be different when using the fork versus the upstream version? If the author has to update submodules manually, they'd need to specify the new commit either way.

This really shows how bad submodules are for dependencies.