The synopsis sections of our manual pages have generally been formatted
in the same way since 2014, when our first manual page was added in
commit 79518af of PR git-lfs#58.  The fixed
portions of the Git LFS command presented in each page's synopsis is
delimited with backticks, and the remainder of the command is left
unformatted.

Our manual page source files were originally written in Ronn and now
use AsciiDoc markup instead.  In both cases, text delimited with backticks
is displayed in a monospace font when our pages are rendered into HTML.
This in itself is consistent with the style we use throughout our manual
pages, as we aim to render all literals as monospace text.

However, we also render all command option flags and argument placeholder
names as monospace text, except within the majority of our synopsis
blocks, where these are displayed in a proportional font.

There are some exceptions, such as in our git-lfs-completion(1),
git-lfs-filter-process(1), and git-lfs-pointer(1) pages, where the entirety
of each line of the synopsis is rendered as monospace text, which is more
consistent with how we display command arguments and flags in the other
sections of our manual pages.

Even in these cases, though, each line of the synopsis is rendered
separately, because we have not placed the entire synopsis within
a literal block.  To prevent the lines being displayed as a continuous
single line, we add trailing hard line breaks in the form of a space
character and a plus ("+") character at the end of the lines.

This is a fragile syntax, though, as can be illustrated by the current
state of our git-lfs-push(1) manual page, where some hard line breaks
were inadvertently omitted when additional lines describing the command's
new --stdin option were inserted into the page's synopsis in commit
e35f407 of PR git-lfs#5086.

Likewise, when we implemented a --stdin option for the "git lfs fetch"
command in commit 5c6daf0 of PR git-lfs#6088,
we added another line to the synopsis section of the git-lfs-fetch(1)
manual page but neglected to add a hard line break as well.

We can avoid these types of issues and format our synopsis sections
in a manner consistent with the rest of our manual page text by using
AsciiDoc source listing blocks with custom subtitutions.  We place
all of the command prototypes in each synopsis section into a single
block, which means we can eliminate the trailing hard line breaks
completely.  We also remove all the backtick delimiters from our
synopsis sections, since these sections will now be fully rendered as
monospace text.

Since commit f11d309 of PR git-lfs#5054
our "mangen" utility has recognized AsciiDoc source listing blocks
and rendered them into plain text appropriately.  (Note that we use the
"mangen" utility to convert our manual page source files into formatted
plain text encapsulated in Go string assignments, which are then output
by the "git lfs help" command.)

In addition to the "git lfs help" command, we also provide manual pages
in HTML and roff formats, which we include in the packages we publish
for each release.  To generate these HTML- and roff-formatted pages we
make use of the Asciidoctor "manpage" converter, which accepts our
AsciiDoc source files as input.

At present, though, the Asciidoctor "manpage" converter always indents
source listing blocks when generating output in the roff format, so when
these pages are viewed with the man(1) command, our synopsis sections
will now be indented, unlike all the content of all of the other sections.

As we would prefer for all of our manual pages' sections to be aligned
evenly, in a subsequent commit in this PR we will introduce a small
Asciidoctor extention module to prevent the indentation of source
listing blocks, but only for the blocks in our synopsis sections and
only when generating output in the roff format.