At present if the git lfs checkout command is invoked with the --to option, a file path, and a "stage" option (one of --base, --ours, or --theirs), but without any object path, a Go panic is reported, because there is an attempt to reference the non-existent first element of the args slice. For example, git lfs checkout --to foo --base reports a panic.

We address this issue by exiting with an error message if the number of additional arguments is not exactly one when --to is supplied along with accompanying file path and one of the "stage" options.

This also covers the situation where the user supplies these options plus spurious additional arguments beyond a single Git LFS object path, since only a single object can be checked out at a given stage into the file specified with --to. (Note that
this object path is not treated as a filepath pattern, unlike the normal git lfs checkout mode of operation.)

To validate this change we expand our "checkout: conficts" test to check the relevant cases, and we also add some checks for other invalid options and arguments, such as when no "stage" option is given, when too many "stage" options are set, or when paths to conflicting files are provided which do not correspond to Git LFS objects.

Note that while our new checks will not catch a Go panic in particular, they would still cause the test to fail if our previous commit's change was not in place, because the expected new error message would not appear.

To accord with our change we also update the git-lfs-checkout(1) manual page to clarify that only a single path should be provided in this case, and that it must reference a conflicting Git LFS object file, not just any file with a merge conflict.

We also add some missing formatting in the Synposis section to ensure the two alternative invocation formats are clearly separated, and we adjust the terminology of some of the user-provided arguments to align better with Git's manual and with other Git LFS manual pages.

Specifically, we use <file> to indicate any file in the filesystem (e.g., as seen in git log --output=<file>), <glob-pattern> to indicate a Git LFS glob pathspec pattern matched according to gitignore(5) rules (similar to the usage in git log --glob=<glob-pattern>, although we match files in the index rather than under .git/refs), and <path> (in this case, <conflict-obj-path>) to indicate a path within the repository. And we expand on the details of each of these terms in the text of the manual page as well.

Finally, we refine and expand the Examples section by adding an example use case for the --to option, and making all the examples follow the same formatting style.