Capture mount dumps and preserve logs when a functional test fails

[tyrielv]

Capture mount dumps and preserve logs when a functional test fails

When a functional test fails in CI, the only diagnostic we get today is whatever
TestResultsHelper.OutputGVFSLogs happens to inline to the console. If a
GVFS.Mount process is hung (the common flaky-failure signature — a test times
out waiting on the mount named pipe with no crash trace), there is no way to see
why after the fact: the process is killed during teardown and its state is lost.

This adds first-class failure diagnostics for the functional tests:

• Mount minidump. On a failed test, before teardown unmounts/kills anything,
  GVFSFunctionalTestEnlistment.CaptureFailureDiagnostics() finds the live
  GVFS.Mount process(es) for the enlistment and writes a full-memory minidump
  via MiniDumpWriteDump (new MiniDump helper, P/Invoke into dbghelp). This
  is exactly what's needed to root-cause a hang.
• Robust log preservation. The enlistment's .gvfs/logs are copied out with
  a fallback that reopens locked/partially-flushed files with a shared
  read handle (FileShare.ReadWrite | Delete), so we still capture logs that a
  live process is holding open.
• CI artifact upload. functional-tests.yaml points diagnostics at a fixed
  directory (GVFS_TEST_DIAGNOSTICS_DIR) and uploads it as
  FailureDiagnostics_<matrix> with if: always().

Everything is best-effort and never throws, so it cannot turn a passing test red
or mask the real failure.

Incidental fix

GetMountProcessIds (extracted from the existing KillMountProcess) matched the
mount command line with a PowerShell -like wildcard built from the enlistment
path with its backslashes doubled. In -like, \ is a literal, not an escape,
so the doubled pattern never matched a real single-backslash command line — it
found zero PIDs. This was a pre-existing latent bug: KillMountProcess has been
silently killing nothing. Now matches on the enlistment's unique leaf id, which
is on the mount command line and needs no escaping.

Validation

Exercised end-to-end in CI via a throwaway harness branch (a smoke test that
Assert.Fail()s with a live mount). The FailureDiagnostics artifact came back
containing GVFS.Mount_<pid>.dmp (~125 MB full-memory dump) plus the preserved
clone/mount/prefetch logs.

[Keith Klein (KeithIsSleeping)]

The asynchronous stdout reader may still be flushing when the PID output is parsed, which can make mount process discovery intermittently miss a live process.

[tyrielv]

You're right -- WaitForExit(int) only guarantees the process exited, not that the async OutputDataReceived callbacks have all fired, so parsing output right after could race the last callback and drop a trailing PID. Fixed by calling the parameterless WaitForExit() right after the timed wait succeeds, which blocks until the redirected-stream reads complete (a no-op if the process already exited). Also rebased onto latest master and squashed -- see f22daab.