In a previous commit in this PR we adjusted the "git lfs checkout"
and "git lfs pull" commands so that when a Git LFS object's contents
can not be written to a file in the working tree, the commands output
a detailed set of error messages rather than just the message "could
not check out <filepath>".

We now add tests to our t-checkout.sh and t-pull.sh test scripts which
validate this change.  Specifically, the new "checkout: read-only
directory" and "pull: read-only directory" tests remove write permissions
on a directory in the working tree after removing a file which is
tracked as a Git LFS object from the directory.  The tests then check
that the "git lfs checkout" and "git lfs pull" commands output a full
set of error messages when they are unable to re-create the file.

Note that for historical reasons we expect that under these conditions
the commands will return a zero exit code, indicating success, rather
than a non-zero exit code, which would indicate failure.  We may adjust
this behaviour in the future, however, so that the commands also return
a non-zero exit code in these cases.

Note also that we use the "icacls" command on Windows to change the
directory write permissions, as the "chmod(1)" command, as emulated by
the Git Bash/MSYS2 environment, does not suffice.  See, for reference:

  https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/icacls

As well, we skip our new tests when running as the "root" user on Unix
systems or with Administrator privileges on Windows systems, since under
these conditions the Git LFS command will still be able to create a
file in the read-only directory.  To ensure we skip the tests when
the user has elevated privileges, we add a skip_if_root_or_admin()
helper function to our t/testhelpers.sh test library and call it at
the start of both of our new tests.

On Unix systems the skip_if_root_or_admin() function exits the test
if the user has an effective uid of zero, as reported in the protected
EUID environment variable in Bash.

On Windows, the function exits after checking for Administrator privileges
by running the "sfc.exe" (System File Checker) command and determining if
it output help text containing the string "SCANNOW", something it should
only do in Administrator mode.  See the following references for further
documentation on this technique:

  https://stackoverflow.com/a/58846650
  https://stackoverflow.com/a/21295806
  https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/sfc