In a previous commit in this PR we revised all the synopsis sections
of our AsciiDoc manual pages so they were formatted consistently using
source listing blocks, which helps us avoid problems with missing
hard line breaks, among other advantages.

However, this change introduces one small but noticeable inconsistency
in the way our manual pages are now displayed by the man(1) program,
due to how the Asciidoctor "manpage" converter handles listing blocks
when generating roff output.  The "manpage" converter always indents
listing and literal blocks by a fixed amount, which is currently set
to four space characters, as seen in the convert_listing() and
convert_literal() methods of the Converter::ManPageConverter Ruby class:

  https://github.com/asciidoctor/asciidoctor/blob/fc0d033577d30adbffba73ce06709292fc2cf3ce/lib/asciidoctor/converter/manpage.rb#L253-L260
  https://github.com/asciidoctor/asciidoctor/blob/fc0d033577d30adbffba73ce06709292fc2cf3ce/lib/asciidoctor/converter/manpage.rb#L269-L276

These methods enclose the content of the blocks with a set of roff
macros, two of which in particular indent and unindent the text.
In general, this is desirable, as we expect to use source listing and
literal blocks within a series of regular paragraphs, and so rendering
them in an indented fashion makes them distinct and recognizable as
examples of source code or other literal text.

Our synopsis sections, though, explicitly do not contain any content
other than Git LFS command prototypes, which we would like to align
with the main content of the other sections, both for visual consistency
and because this is the standard format used for all Unix manual pages.

Because the roff indentation macros are, at present, hard-coded into
the Asciidoctor "manpage" converter's methods, we can not override
them with simple AsciiDoc options or flags.

Instead, to achieve the formatting we desire for our synopsis sections,
we introduce a small Asciidoctor extension module which subclasses
the Converter::ManPageConverter class and provides its own definition
of the convert_literal() method.  In this method, we first call the
parent class's method of the same name, and then modify its output
to remove the roff indentation and unindentation macros, but only
if the current document node's "role" attribute is set to "synopsis".

To locate the indentation and unindentation macros in our extension
module, we define a regular expression which matches the roff macros
output by the convert_literal() method of the Converter::ManPageConverter
class, which are the ".RS" ("region start") and ".RE" ("region end")
indentation macros.  We expect the former will be followed by an
numeric value, which currently is always "4", but we allow for any
possible value here in case Asciidoctor changes the indentation amount
for listing blocks in the future.

We also allow for these macros to be preceded by ".if" conditional
requests with the "n" condition, which is how Asciidoctor generates
them at present.  The "n" (i.e., "nroff") condition is normally set
true by default if the output device is a terminal.  See, for reference:

  https://www.gnu.org/software/groff/manual/groff.html#Indented-regions-in-ms
  https://www.gnu.org/software/groff/manual/groff.html#troff-and-nroff-Modes

Finally, we add a custom "role" attribute to the source listing blocks
in all of our manual pages' synopsis sections, and we update our Makefile
so Asciidoctor will find and load our new extension module when generating
roff output with the "manpage" converter.

The documentation of our commands generally conforms to the conventions
of the Unix and Git manuals.  However, a number of inconsistencies are
present in both the content and format of our manual pages.

In a previous commit in this PR we revised all the synopsis sections
of our AsciiDoc manual pages so they were formatted consistently using
source listing blocks, which helps us avoid problems with missing
hard line breaks, among other advantages.

In a subsequent commit in this PR we expect to make additional changes so
that when our manual pages are rendered into HTML or roff, either by an
Asciidoctor converter or by GitHub's UI, the synopsis sections of our
pages will identify literals using boldface text and replaceable arguments
using italics.  This will bring our documentation into closer alignment
with the standards of the Linux man-pages project:

  https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man/man7/man-pages.7?id=a5342ef55f0a96790bf279a98c9d2a30b19fc9eb#n200

However, our "mangen" program should continue to render our manual pages
into plain text, as this is the format in which they are output by the
"git lfs help" command.  We will therefore update this program to remove
the AsciiDoc markup for boldface and italic text from the content of the
synopsis sections of our manual pages.

Before we make these changes, we first need to revise the synopsis
sections of several manual pages whose existing format would conflict
with the additional AsciiDoc markup we intend to use to identify
italic text in particular.

AsciiDoc uses underscore and asterisk characters to demarcate italic and
boldface text, respectively.  Since we expect to make use of these
formatting characters, we will also have to update our "mangen" program
so that it removes them from our synopsis sections.

Ultimately, we intend to only use the underscore and asterisk characters
in constrained pairs rather than unconstrained pairs, meaning they should
only appear immediately before or after terms, never within a term:

  https://docs.asciidoctor.org/asciidoc/latest/text/#constrained
  https://docs.asciidoctor.org/asciidoc/latest/text/#unconstrained

However, adjusting our "mangen" program to remove underscore and
asterisk characters from synopsis sections will be substantially
simpler if we do not have to account for this difference.  We can just
remove all such characters from our synopsis sections instead of trying
to match formatting characters only when they appear between the start
or end of a term and either whitespace or the start or end of a line.

For this reason, we would prefer that no underscore characters appear
in any terms in our synopsis sections, as they do now in our
git-lfs-post-checkout(1) and git-lfs-post-merge(1) manual pages.
At present, we define the replaceable arguments of those two commands with
terms that contain underscore characters, such as "is_branch_checkout"
and "is_squash".

As a further incentive to replace the underscore characters in these
two manual pages' synopsis sections, the Git project's guidelines for
manual page documentation state that command examples should use only
"dashes" (i.e., the ASCII "hyphen-minus" character) to separate words:

  https://github.com/git/git/blob/c4a0c8845e2426375ad257b6c221a3a7d92ecfda/Documentation/CodingGuidelines#L871-L878

Therefore, both to bring our documentation into closer conformance with
Git's standards and to allow our changes to the "mangen" program to be
as simple as possible, we change the underscore characters in the
git-lfs-post-checkout(1) and git-lfs-post-merge(1) manual pages'
synopsis sections to hyphen characters.

In previous commits in this PR we revised all the synopsis sections of
our AsciiDoc manual pages so they are formatted consistently using source
listing blocks, and ensured that no AsciiDoc inline formatting characters
appear in the synopsis sections.

With these changes in place we are now able to reformat our synopsis
sections so that when our manual pages are rendered into HTML or roff,
either by an Asciidoctor converter or by GitHub's UI, our synopses will
consistently identify literals using boldface text and replaceable
arguments using italics.  In doing so, we will bring our documentation
into closer alignment with the standards of the Linux man-pages project:

  https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man/man7/man-pages.7?id=a5342ef55f0a96790bf279a98c9d2a30b19fc9eb#n200

First, we apply the AsciiDoc "quotes" substitution rule to all of our
synopsis sections, so that Asciidoctor will respect the AsciiDoc inline
formatting characters we want to use, namely the underscore and asterisk
characters for boldface and italic text, respectively.  We also need to
specify the "verbatim" rule, since we are overriding the default rule
settings for source listing blocks, but still want to start by applying
that rule:

  https://docs.asciidoctor.org/asciidoc/latest/subs/#verbatim-group
  https://docs.asciidoctor.org/asciidoc/latest/subs/quotes/

We then add the appropriate inline formatting markup to all of the
synopsis sections of our manual page source files.  We demarcate all
literals using boldface text, and all replaceable arguments using italics.

Note that in the our git-lfs-pointer(1) manual page we make use of
unconstrained formatting pairs in order to render the existing synopsis
text without other changes, as this page is the only one where we include
the optional equals sign character between literal and replaceable
arguments, e.g., "--file=path/to/file" instead of "--file path/to/file".
We expect to further revise this page in a subsequent PR at which time we
will also rewrite a number of other pages' synopsis sections so they use
a consistent style for all of their text and placeholder arguments, and
only require the use of constrained formatting pairs:

  https://docs.asciidoctor.org/asciidoc/latest/text/#constrained
  https://docs.asciidoctor.org/asciidoc/latest/text/#unconstrained

Next, we revise our "mangen" program so that it continues to render
our manual pages into plain text, as this is the format in which they are
output by the "git lfs help" command.  Specifically, we update this
program to remove the AsciiDoc markup for boldface and italic text from
the content of the synopsis sections of our manual pages.

The "mangen" program has recognized the start and end of AsciiDoc source
listing blocks since commit f11d309 of
PR git-lfs#5054, when we first migrated our manual pages' source files to the
AsciiDoc format.  We now expand this logic so that it detects when a
source listing block is defined with our custom "synopsis" role and
sets an internal "isSynopsisSourceBlock" flag, which remains "true" until
the block's final line is encountered.

While the "isSynopsisSourceBlock" flag is set we apply a simple regular
expression which removes any asterisk or underscore characters from
each line.  As we noted in a previous commit in this PR, this approach
is significantly less complicated than if we attempted to match inline
formatting characters only when they appear between the start or end of
a term and either whitespace or the start or end of a line.  Further, this
regular expression also allows us to handle unconstrained formatting
pairs, which as explained above we make use of in our git-lfs-pointer(1)
manual page for now.

Finally, we introduce a new t/t-usage.sh shell test script with a single
initial "usage: no command specified" test which verifies that our
git-lfs(1) manual page is output by the multiple variants of the "git lfs"
and "git-lfs" commands.  Note that we cannot test using the "git lfs -h"
or "git-lfs -h" variants because at present we do not support the -h option
when it is provided without a Git LFS command name, as discussed in git-lfs#6168.