As of Go 1.24, if the Go version number in the "go.mod" file is set to
1.24 or higher, the "go vet" command now reports misuses of non-constant
strings as format strings.  In previous commits in this PR we have now
resolved all but one of the instances where we provided a non-constant
string as a format string.  The remaining instance is our use of the
Errorf() function of the "fmt" package from the Go standard library
at the end of the Combine() function in our "errors" package.

The Combine() function was added to our custom "errors" package in
commit 08e3e5b of PR git-lfs#1870, originally
for use in the "locking" package.  This function merges multiple
errors into a single error by concatenating their error messages
with a newline separator character between each original message.

In Go 1.20 the Join() function was added to the "errors" package
of the Go standard library, and it performs the same concatenation
of error messages as our Combine() function, including the use of a
newline character as a separator between the original messages, except
that it delays the concatenation until the Error() method is called.

To resolve the remaining case where we pass a non-constant string as
a format string, we remove the Combine() function from our "errors"
package and replace it with a Join() function that simply invokes
the Join() function of the standard library's "errors" package,
which we can expect to be defined as we currently require the use of
at least Go 1.21 (per the Go version specified in our "go.mod" file).

To make this change, we alias the standard library's "errors" package
as "goerrors", following the pattern established in our "lfshttp"
package where we use that alias as well.

We then revise the two callers of our Combine() function to make
use of the new Join() function instead.  One of these callers is the
startConnection() function in our "ssh" package, which simply joins
two errors, and the other caller is the FixLockableFileWriteFlags()
method of the Client structure in our "locking" package, which
collects zero or more errors while iterating over a list of files
and repeatedly calling another method.

Because the Join() functions accept variadic arguments rather than
an array of errors, we revise these callers to pass the errors
they intend to concatenate as direct arguments rather than in an
array.  For the FixLockableFileWriteFlags() method this means that
as it iterates over its list of files, if any errors occur we
immediately call the Join() function to add them to the error value
we return at the end of the function, whereas previously we appended
the errors to an array, and then called the Combine() function after
the loop exited to concatenate any errors in the array into the
function's final error return value.

As of Go 1.24, if the Go version number in the "go.mod" file is set to
1.24 or higher, the "go vet" command now reports misuses of non-constant
strings as format strings.  In previous commits in this PR we have now
resolved all but one of the instances where we provided a non-constant
string as a format string.  The remaining instance is our use of the
Errorf() function of the "fmt" package from the Go standard library
at the end of the Combine() function in our "errors" package.

The Combine() function was added to our custom "errors" package in
commit 08e3e5b of PR git-lfs#1870, originally
for use in the "locking" package.  This function merges multiple
errors into a single error by concatenating their error messages
with a newline separator character between each original message.

In Go 1.20 the Join() function was added to the "errors" package
of the Go standard library, and it performs the same concatenation
of error messages as our Combine() function, including the use of a
newline character as a separator between the original messages, except
that it delays the concatenation until the Error() method is called.

To resolve the remaining case where we pass a non-constant string as
a format string, we remove the Combine() function from our "errors"
package and replace it with a Join() function that simply invokes
the Join() function of the standard library's "errors" package,
which we can expect to be defined as we currently require the use of
at least Go 1.21 (per the Go version specified in our "go.mod" file).

To make this change, we alias the standard library's "errors" package
as "goerrors", following the pattern established in our "lfshttp"
package where we use that alias as well.

We then revise the two callers of our Combine() function to make
use of the new Join() function instead.  One of these callers is the
startConnection() function in our "ssh" package, which simply joins
two errors, and the other caller is the FixLockableFileWriteFlags()
method of the Client structure in our "locking" package, which
collects zero or more errors while iterating over a list of files
and repeatedly calling another method.

Because the Join() functions accept variadic arguments rather than
an array of errors, we revise these callers to pass the errors
they intend to concatenate as direct arguments rather than in an
array.  For the FixLockableFileWriteFlags() method this means that
as it iterates over its list of files, if any errors occur we
immediately call the Join() function to add them to the error value
we return at the end of the function, whereas previously we appended
the errors to an array, and then called the Combine() function after
the loop exited to concatenate any errors in the array into the
function's final error return value.

In PR git-lfs#1870, which was based on the work in PR git-lfs#1822, we introduced
support for "lockable" files whose permissions would be managed by
several new Git LFS commands such as "git lfs post-checkout" and
"git lfs post-merge", both of which we register as Git hooks.

In commit 585befa of PRs git-lfs#1822 and git-lfs#1870
we added manual pages for these two commands.  (Although these PRs
also introduced the "git lfs post-commit" command, they did not
include a manual page for it, so we added one belatedly in commit
ae5d5b0 of PR git-lfs#4052.)

From the time it was written, our git-lfs-post-checkout(1) manual page has
indicated that the command accepts three arguments.  This accurately
reflects the fact that Git will invoke our hook command with parameters
specifying the SHAs from before and after the checkout operation, plus
a status flag indicating whether a branch checkout was performed or not.

However, our manual page does not explain what values these arguments
are expected to contain, other than by dint of the names given to the
arguments in the page's synopsis section.  We therefore expand our
description of the "git lfs post-checkout" command to detail the values
Git will provide in each of the three arguments.

We also take the opportunity to adjust the name of the second argument
to clarify that we expect this parameter to contain a Git revision SHA
and not the name of a Git reference such as a branch or tag.  As well,
we replace the underscores in the argument names with hyphens to match
the style we use in all our other manual pages for the names of command
parameters.

In PR git-lfs#1870, which was based on the work in PR git-lfs#1822, we introduced
support for "lockable" files whose permissions would be managed by
several new Git LFS commands such as "git lfs post-checkout" and
"git lfs post-merge", both of which we register as Git hooks.

In commit 585befa of PRs git-lfs#1822 and git-lfs#1870
we added manual pages for these two commands.  (Although these PRs
also introduced the "git lfs post-commit" command, they did not
include a manual page for it, so we added one belatedly in commit
ae5d5b0 of PR git-lfs#4052.)

From the time it was written, our git-lfs-post-merge(1) manual page has
indicated that the command accepts a single "<is_squash>" argument.
This accurately reflects the fact that Git will invoke our hook command
with a single flag parameter that indicates whether or not a squash merge
was performed.

However, our "git lfs post-merge" command disregards this parameter
entirely, so we adjust our manual page now to clarify that this command
requires no arguments and ignores the one provided by Git.