Enhance support for GPG signed tags

[ChrisMcD1]

• PR Description

When using gpg signing on tags via the git config tag.gpgSign=true, it is not possible to do a lightweight tag. You must do an annotated tag (Which is allowed to have an empty description).

This PR augments the existing WithGpgHandling helper to allow it to specifically target commit signing and tag signing. It then uses that handler, and creates an annotated tag, when the git config demands tag GPG signing. By default it will launch the tag signing in a new subprocess. This does require that users click an extra <enter> after creating a signed tag, but this is currently the behavior for signed commits, so I don't feel too bad about that. If they want, they can use the LazyGit configuration option of git.overrideGpg: true to promise to LazyGit that they do not need a GPG sub-process (because they reliably already have gpg-agent or similar running in the background). This again matches the current behavior for GPG signed commits.

This has no integration test because we don't have the machinery set up in place to set up a GPG key inside of our integration test framework.

Fixes #2955

• Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[stefanhaller]

Looks good, although I would prefer if we could actually make it work for people who don't have a gpg-agent running. Throwing the DisabledForGPG error should really be an exception for cases where it's too hard to support.

As for making it work: we do have the WithGpgHandling helper already, all we need to do it pass in the git config to check as a criterion. Instead of what you did here (add a second NeedsGpgSubprocessForX function), I would have kept the UsingGpg function and passed in the git config there (probably as a named constant). Let me know if I'm not being clear enough.

See also #3423 (comment).

[ChrisMcD1]

Updated the PR to not create that exception anymore!

It was my first time creating an enum-like construct in Go with the GpgConfigKey, so please let me know if you think this is an appropriate location to use one.

[ChrisMcD1]

We implicitly now refresh on more scopes, since the WithGpgHandler calls Refresh with no scopes list applied. I'm assuming that refreshes all scopes. Don't think this is a major problem, but let me know if it is !

[stefanhaller]

I agree that it's not a major problem, but on the other hand it's also easy to fix, so why not: 81064e7

[stefanhaller]

Looks great now, thanks. Yes, I think the use of the enum is perfect here.

[stefanhaller]

@ChrisMcD1 I'd be ready to merge this, but didn't want to without getting some sort of acknowledgment for the commit I added.

Also, the PR description no longer matches what the branch does; it would be good if you could update it, since it ends up in the merge commit.

[ChrisMcD1]

@stefanhaller I have updated the PR description!

I could have sworn that I acknowledged that commit, but I now see I only acknowledged it in my own head 😆
It looks good to me!