On Windows (only), a file created by NamedTemporaryFile can't be
opened again while it is already open. That causes some tests to
fail with PermissionError even when the code under test is correct.

To fix it without making the test code longer or more complicated,
we can use the tmp_path pytest fixture, which makes a temporary
directory (separate for each test and each run) where we can create
whatever file(s) we need, and which handles cleanup. This has the
further benefit of being a more idiomatic way to work with
temporary files in pytest tests.

This commit makes that change for test_file_cli.

For improved readability.

As in test_file_cli, these failed with PermissionError on Windows
by trying to open a file created by NamedTemporary file while it is
already open. This likewise switches to using the pytest tmp_path
fixture. The api_key_file fixture is modified to request and use
it, and to provide a Path object, which test case functions call
write_text on instead of printing and flushing.

Since this was a major change to the api_key_file fixture, I've
also taken the opportunity to have it delegate patching and
automatically unpatching openai.api_key_path to another pytest
fixture, allowing its code to be shorter and simpler.

(It's unused because of how openai.api_key_path now gets patched.)

This fixes one of the problems running test_long_examples_validator
on Windows: the command run by subprocess.run giving a "The
filename, directory name, or volume label syntax is incorrect"
error.

It happens because the command to run is specified as a list of one
element that is a string for the shell to interpret, rather than
that string itself. This ends up working on Unix-like systems, but
on Windows it results in extra quotation (adjacent `"` characters)
that cmd.exe doesn't understand.

This changes the subprocess.run call to what was probably intended,
but it may make sense to modify it further to make it more
consistent with how the subprocess module is used in other tests.

Note that test_long_examples_validator is not fully fixed; now it
raises PermissionError on Windows (the NamedTemporaryFile issue).

This makes the subprocess.run call in test_long_examples_validator
more similar to how other tests use the subprocess module, by
passing a list of separate command-line arguments instead of using
a shell to parse a single string.

This fixes the Windows-specific PermissionError that happened
because of how NamedTemporaryFile was used. As in other such tests,
the pytest tmp_path fixture is now used instead.

In test_long_examples_validator, subprocess.run was treating the
child process's standard streams as UTF-8 encoded. It's usually
good practice to specify UTF-8, but in this case, the child
process uses a different encoding for its standard streams on
Windows.

On many Windows systems, this is CP-1252 (Windows-1252), and the
curly apostrophe in the "After you’ve fine-tuned a model..."
message triggers a UnicodeDecodeError. Although the message could
be changed, the test's correcteness probably shouldn't rely on
knowledge of the output besides what we specifically test.

This has subprocess.run use the system default encoding for the
child process's standard streams. Since the child process is itself
Python, this should match in nearly all circumstances.

- Code style (variable names, keyword argument order)
- File encoding (specify as UTF-8 in all, not just some, cases)
- Child process standard stream encoding (system default)

(The encoding of the temporary files, and of stdin/stdout for the
child processes, are separate. Even when text from the temporary
files is output by a child process, it is encoded with whatever the
stream's encoding is, which for standard streams is the default
system encoding.)

When using Python 3.7 on Windows (but not on other systems, and not
on Windows with any later version of Python), subprocess.run and
related functions don't support Path objects as command line
arguments, due to python/cpython#85919.

This explicitly converts them to str in those calls. This change
can be undone whenever this codebase drops Python 3.7 support.