In a previous commit in this PR we introduced a new utility program
for our test suite, lfstest-genrandom, which reliably produces random
data on all the platforms we support, either as raw binary data or
using one of several forms of Base64 encoding.

We now make use of that program throughout our test suite, in place
of reading from /dev/urandom directly.  (Note that because the
lfstest-genrandom program uses the Go crypto/rand package to collect
the random data, on macOS and Linux systems the ultimate source of the
data will still be /dev/urandom, since the Go package reads from
that special file on those platforms.  On Windows, however, the Go
package makes use of the native Windows ProcessPrng API, so we will
no longer be dependent on the Git Bash environment to provide a
simulated /dev/urandom on Windows.)

In most cases, we pass the --base64 flag to our lfstest-genrandom
program, which allows us to eliminate many calls to the base64(1)
command.  We can also pass the exact size of the returned data
we desire as a command-line argument, which eliminates the need
to pipe the data through the head(1) command.

In two instances, in the remove_and_create_local_repo() and
remove_and_create_remote_repo() functions in our t/fixtures/migrate.sh
file, we use the --base64url flag so that we can use the returned
strings as directory name suffixes without further processing.
Previously, we had to pipe the data through base64(1), head(1),
sha256sum(1), and cut(1) in order to ensure we had a random string
safe for use in a directory name.

And in the setup_local_branch_with_special_character_files() function
in our t/fixtures/migrate.sh file we don't pass any flags to the
lfstest-genrandom program as we want raw binary data for the test
files created by that function.

In previous commits in this PR we introduced a new utility program
for our test suite, lfstest-genrandom, which reliably produces random
data on all the platforms we support (in several forms of Base64
encoding, or as raw binary data), and then converted much of our test
suite to make use of this new program.

As noted in one of those commits, one test in our t/t-prune.sh test
script makes use of the uuidgen(1) command to populate some Git LFS
objects with arbitrary text, but as this command does not exist in
the Git Bash environment on Windows, the objects actually have empty
data on that platform.  The test still passes because it doesn't depend
on the length of the random data, and because the non-zero exit code
caused by the missing uuidgen(1) command is ignored as it appears earlier
in a pipeline whose final command (our lfstest-testutils program)
always succeeds.

We therefore revise this "prune verify large numbers of refs" test
(which was added in commit dd19c1b of
PR git-lfs#1861) to call our new lfstest-genrandom program instead of the
uuidgen(1) command.  We pass the --base64 flag to our program and request
a slightly larger size for the output Base64-encoded string than the
length of a UUID, just to ensure we are using a similar amount of random
data as before, although this doesn't actually affect the success or
failure of the test.

We also adjust the test so that it does not create the Git LFS objects
with sizes that do not match the length of their arbitrary content.
(Again, the test passed despite this inconsistency in its test data.)

In commit 96775c6 of PR git-lfs#2929 the
"migrate import (--object-map)" test was added to the test suite for
the "git lfs migrate import" command to validate the --object-map option
for that command, which was introduced in the same PR.  This test
makes use of the mktemp(1) shell command to generate a unique temporary
directory, into which the test then writes several files including
the Git LFS migration's object map file.

Likewise, in commit 7632a20 of PR git-lfs#3084,
a similar "migrate export (--object-map)" test was added to the test
suite for the "git lfs migrate export" command, which was introduced
in that PR, and this test also uses the mktemp(1) shell command to
create a unique temporary directory.

However, neither test removes these temporary directories after
completion, so they remain in place indefinitely in whatever system
location is used by the mktemp(1) command.  This is in addition to the
temporary directory created by the mktemp(1) command which is used
throughout all our test suites, whose path we store in the
GIT_LFS_TEST_DIR variable so it can be reused by all test suites after
the first one to run.  (At least, that is the intent of the variable,
but in practice, because we do not export it, and because each test
script runs in its own shell session, each script creates another
temporary directory.  We will address this issue in a subsequent PR.)

In a previous commit in this PR we introduced a new lfstest-genrandom
utility program for our test suite, so we can now make use of it to
replace both instances where our migration tests make an extra call
to the mktemp(1) shell command (beyond the one used to populate the
GIT_LFS_TEST_DIR variable).

In both tests, we now create a unique directory whose path begins
with the path in the GIT_LFS_TEST_DIR variable, followed by a directory
name partially generated by our lfstest-genrandom program.  We pass
the --base64url flag to the program ensure it returns only characters
safe to use in a file or directory name on any OS platform.

In commit cc41ca5 we changed the
template used for our call to mktemp(1) to add a suffix of "XXXXXX"
in order to comply with the requirements of the GNU version of that
command, which expects at least 3 "X" characters in a template
for a temporary file or directory name.

However, on macOS, the BSD version of mktemp(1) treats these
as literal "X" characters if the -t option is used, because in
this case the following argument is interpreted as a prefix,
not a template.  Thus we actually create temporary directories
on macOS of the form /var/folders/.../git-lfs_TEMP.XXXXXX.<random>,
with 8 random characters appended by the command.

Since the "X" characters are unnecessary in this case, we adjust
our definition of the TEMPDIR_PREFIX variable to leave them off
when our tests are running on macOS.