functional tests: add dev mode for running without admin

[tyrielv]

Running functional tests today requires admin privileges (to install a Windows service via sc create) and a system-wide GVFS installation (from C:\Program Files). This makes the edit-build-test cycle heavyweight for developers.

This change adds an opt-in dev mode, activated via environment variable, that removes both requirements. When GVFS_FUNCTIONAL_TEST_DEV_MODE=1:

• The test service runs as a console background process instead of a Windows service (new --console flag on GVFS.Service.exe)
• Test binaries are resolved from the build output (GVFS.Payload) via GVFS_DEV_OUT_DIR, not C:\Program Files
• Service data directories are redirected to user-writable temp paths via GVFS_COMMON_APPDATA_ROOT and GVFS_SECURE_DATA_ROOT env vars
• ProjFS IsReady() no longer fails when FilterAttach returns ACCESS_DENIED — if ProjFS is already running, the filter is attached and non-elevated mounts can proceed

A new RunFunctionalTests-Dev.bat script sets all the env vars and runs tests from build output in one step.

The existing RunFunctionalTests.bat behavior, CI pipeline, and admin install flow are completely unchanged — all new code paths are gated behind environment variables that are not set by default.

Prerequisite: ProjFS must have been enabled on the machine at least once (i.e., GVFS was installed previously or the ProjFS optional feature was enabled).

[KeithIsSleeping]

Clean, well-gated addition — all new code paths are behind environment variables that are unset by default, and existing CI/production behavior is completely untouched. The console mode service, build-output path resolution, and data directory redirection all work together nicely to remove the admin + system-install requirement for the edit-build-test cycle.

Reviewed the env var overrides in WindowsPlatform.Shared.cs (GVFS_SECURE_DATA_ROOT, GVFS_COMMON_APPDATA_ROOT) — since the production service runs as LOCAL SYSTEM and doesn't inherit user-level env vars, there's no privilege escalation concern. Setting system-level env vars requires admin (already game over). These only affect the user's own gvfs.exe process, which is the intended dev mode behavior.

One optional suggestion:

ProjFS ACCESS_DENIED check — The string-based check error.Contains(AccessDeniedResult.ToString()) in IsReady() relies on TryAttach formatting the HRESULT as "0x80070005" in the error message. If TryAttach ever changes its error format, this would silently break. Consider having TryAttach return the HRESULT as a structured value (e.g., an out uint parameter) for a more robust check. Not a blocker — the current approach works and the preconditions (IsServiceRunning + IsNativeLibInstalled) narrow the window significantly.