The "git lfs ls-files" command was added in PR git-lfs#122 (technically,
the precursor "git media ls-files" command) and its test suite
converted to shell tests in PR git-lfs#336; however, the basic functionality
of the command has never had tests which confirm it handles files
in subdirectories appropriately.  (Some tests added in later PRs which
do check files in subdirectories under specific conditions, such as
with the --exclude option or with non-ASCII characters in subdirectory
names.)

As we expect to expand this command's test suite in subsequent commits
in this PR, we first add a new test which simply confirms that the
normal output of the command, and the output with the --debug option,
perform as expected when files have been both added and removed within
a subdirectory.

We also add a test which confirms the same behaviour when the --json
option is used.  The use of a separate test for this option was
preferred in PR git-lfs#5007 when the --json option was first introduced (rather
than overloading the existing tests, as was done for the --debug option
when it was added in PR git-lfs#2540), so we follow that model here as well.

In commit 2082b26 of PR git-lfs#681 the
"git lfs ls-files" command was enhanced to include in its normal
output a simple symbolic indicator of whether a full copy of a Git
LFS object existed as a file in the working tree, with a "*" character
indicating the presence of such a file, and a "-" indicating the file's
absence.  While some tests were added at this time, none were added which
check the command's output when a file is absent from the working tree.

Later, in commit 1565e63 of PR git-lfs#2540,
the --debug option was added to the "git lfs ls-files" command, which
provides more extensive output, including separate Boolean fields
indicating whether a Git LFS object exists as either a file in the
working tree or as a cached object file.  Again, while some tests were
added for this new functionality, they do not check the cases where files
are absent from either the working tree or the Git LFS object cache.

As we expect to resolve a bug with the display of these data files
in a subsequent commit in this PR, we first introduce a new test
which validates the existing (and correct) behaviour.  (Notably,
this test only runs the "git lfs ls-files" command in the root of the
working tree; if we executed the command while in a subdirectory,
the output would not be correct, and this is the bug we will resolve
in another commit in this PR.)

We also add a test which confirms the same behaviour when the --json
option is used.  The use of a separate test for this option was
preferred in PR git-lfs#5007 when the --json option was first introduced (rather
than overloading the existing tests, as was done for the --debug option
when it was added in PR git-lfs#2540), so we follow that model here as well.

As reported in the following issue comment, the "git lfs ls-files"
command does not report the presence or absence of Git LFS object files
in the working tree correctly unless the command is run the root
directory of the working tree:

git-lfs#1189 (comment)

We resolve this problem by ensuring that the full, canonicalized path
to the working tree is prepended by the fileExistsOfSize() helper
function to the paths of the files whose presence it checks with the
os.Stat() function.

We then add two new tests which validate the correct behaviour of the
command when it is run in a subdirectory of the working tree.  These
tests would fail without the accompanying bug fix to the command.

We also add another two new tests which confirm the same behaviour when
the --json option is used.  The use of a separate test for this option was
preferred in PR git-lfs#5007 when the --json option was first introduced (rather
than overloading the existing tests, as was done for the --debug option
when it was added in PR git-lfs#2540), so we follow that model here as well.

In commit 2082b26 of PR git-lfs#681 the
"git lfs ls-files" command was enhanced to include in its normal
output a simple symbolic indicator of whether a full copy of a Git
LFS object existed as a file in the working tree, with a "*" character
indicating the presence of such a file, and a "-" indicating the file's
absence.  While some tests were added at this time, none were added which
check the command's output when a file is absent from the working tree.

Later, in commit 1565e63 of PR git-lfs#2540,
the --debug option was added to the "git lfs ls-files" command, which
provides more extensive output, including separate Boolean fields
indicating whether a Git LFS object exists as either a file in the
working tree or as a cached object file.  Again, while some tests were
added for this new functionality, they do not check the cases where files
are absent from either the working tree or the Git LFS object cache.

As we expect to resolve a bug with the display of these data files
in a subsequent commit in this PR, we first introduce a new test
which validates the existing (and correct) behaviour.  (Notably,
this test only runs the "git lfs ls-files" command in the root of the
working tree; if we executed the command while in a subdirectory,
the output would not be correct, and this is the bug we will resolve
in another commit in this PR.)

We also add a test which confirms the same behaviour when the --json
option is used.  The use of a separate test for this option was
preferred in PR git-lfs#5007 when the --json option was first introduced (rather
than overloading the existing tests, as was done for the --debug option
when it was added in PR git-lfs#2540), so we follow that model here as well.

As reported in the following issue comment, the "git lfs ls-files"
command does not report the presence or absence of Git LFS object files
in the working tree correctly unless the command is run the root
directory of the working tree:

git-lfs#1189 (comment)

We resolve this problem by ensuring that the full, canonicalized path
to the working tree is prepended by the fileExistsOfSize() helper
function to the paths of the files whose presence it checks with the
os.Stat() function.

We then add two new tests which validate the correct behaviour of the
command when it is run in a subdirectory of the working tree.  These
tests would fail without the accompanying bug fix to the command.

We also add another two new tests which confirm the same behaviour when
the --json option is used.  The use of a separate test for this option was
preferred in PR git-lfs#5007 when the --json option was first introduced (rather
than overloading the existing tests, as was done for the --debug option
when it was added in PR git-lfs#2540), so we follow that model here as well.