Add reference to hx-preserve to the example at "Preserving File Inputs after Form Errors"

[Matt544]

Description

I have added a second approach to preserving file inputs after form errors (in the example at file-upload-input.md), using hx-preserve.

The approach currently suggested requires a restructuring of the form that will not always be feasible or convenient. I have found that adding hx-preserve to the file input
causes the expected behavior: the user does not have to choose a file again before
re-submitting the form.

The approach is:

<form method="POST" id="binaryForm" enctype="multipart/form-data" hx-swap="outerHTML" hx-target="#binaryForm">
    <input hx-preserve id="someId" type="file" name="binaryFile">
    <button type="submit">Submit</button>
</form>

I feel this change is necessary because the current version of file-upload-input.md
leaves the impression that there is no htmx attribute that can preserve the file input's
value if the input is within the area that htmx will swap. I'm a little
embarrassed to say that this is the conclusion I drew when I saw the current version of
file-upload-input.md and I charged ahead and made an extension that moved my input out
of the swap zone and put it back after the swap. My bad. But it might help others to
point out that hx-preserve is available for this use case.

Testing

My own testing on the hx-preserve approach shows it can acheive the following behaviour:

• if the form has errors and is returned, the original file input choice is preserved
  and the form can be successfully re-submitted.

• if the file field has errors on it, they will be displayed provided that hx-preserve was
  placed in the input only and not the errors element (e.g. ol.errorlist)

• if you want the file upload input to return without the user's chosen file
  because the field was invalid, you can manage that on the server side by omitting
  the hx-preserve attribute when the field has errors. (For example, if the user
  chooses an invalid file type, you may want the file field to come back with no
  value so the user is forced to make another choice.)

Checklist

• I have read the contribution guidelines
• I have targeted this PR against the correct branch (master for website changes, dev for
  source changes)
  • I have tried to target the master branch. Sorry if that didn't work!
• This is either a bugfix, a documentation update, or a new feature that has been explicitly
  approved via an issue
• I ran the test suite locally (npm run test) and verified that it succeeded
  • Nope. This PR address documentation only, under www.