lang/ghc: use getexecpath(3) for executablePath on OpenBSD
getexecpath(3) is new in OpenBSD 8.0. Without it ghc-internal falls through
to the argv[0] fallback and System.Environment.executablePath is Nothing.
Also let ghc-boot use base's executablePath, choosing at run time so the port
still builds with a bootstrap compiler whose base predates getexecpath(3),
and mark openbsd as query-capable in the executablePath test.
Bump REVISION for the getexecpath change
System.Environment.executablePath goes from Nothing to a working query, and
getExecutablePath from argv[0] to a canonicalized absolute path, so the
package behaves differently and needs to be distinguishable.
OK kili@
Revert to gnupg-2.5.22 because gnupg-2.5.23+ breaks mail/notmuch
mail/notmuch uses gmime -> gpgme -> gnupg to decrypt PGP-encrypted
messages, and check for that feature in it configure script. Since
commit 2e6549f5de5307e3e84c1ffa5e762d14266546ba
gpg: Preliminary support for importing some rfc-9980 secret keys.
gpg-agent now appears unable to export the "session key" used by notmuch
tests, so gpg has no key to pass back to gpgme/gmime. The code in
notmuch/configure mimics the code in notmuch/util/crypto.c so we can
expect this to be an actual regression. Revert to the previous gnupg
release to unbreak bulk builds and avoid regressions.
Reported by sthen@
