Fix Could not chdir in tw.exe for long runfiles paths on Windows

[rdesgroppes]

Description

On Windows, bazel test fails for tests run through the native test wrapper (tw.exe) whose runfiles directory path exceeds MAX_PATH (260 characters), with ERROR_FILENAME_EXCED_RANGE (206) from ChdirToRunfiles's call to SetCurrentDirectoryW.

The \\?\ extended-length prefix used by #29921 for CreateProcessW's lpApplicationName would not help here: SetCurrentDirectoryW ignores that prefix regardless of length, as stated by MicrosoftDocs/feedback#1441.
=> declare longPathAware in tw.exe's manifest (tw_manifest.xml, embedded via tw_resources.rc and windows_resources in tools/test/BUILD), which Windows 10 1607+ honors for SetCurrentDirectoryW once paired with the LongPathsEnabled registry opt-in.

Once ChdirToRunfiles succeeds into a long directory, StartSubprocess's CreateProcessW call also needs its current directory passed explicitly: implicit inheritance (lpCurrentDirectory=nullptr) otherwise fails with ERROR_INVALID_PARAMETER once cwd exceeds MAX_PATH, even from a longPathAware process.
=> populate it so that windows::WaitableProcess::Create can shorten it internally (through AsShortPath), like it does for the executable's own path.

The new testLongRunfilesPathChdir in test_wrapper_test.py exercises both fixes: the cwd fix always fails in StartSubprocess when missing, while a missing manifest can surface as either ChdirToRunfiles's error or rules_cc's Runfiles::Create (FindTestBinary) failing first, depending on path length.

Motivation

Fixes #30609

Build API Changes

No

Checklist

• I have added tests for the new use cases (if any).
• I have updated the documentation (if applicable).

Release Notes

RELNOTES: Fix Could not chdir in tw.exe for long runfiles paths on Windows.

[fmeum]

Suggested change

	long_name = 'x' * 150
	long_name = 'x' * 256

would make it more obvious that this is long enough.

[rdesgroppes]

Tried 'x' * 256 first, but it breaks the build for an unrelated reason: bisecting, 233 still passes but 234 fails with ERROR_INVALID_NAME, because Bazel writes a <name>.exe.runfiles_manifest file for each test target.
It turns out individual path components are capped at 255 characters, per Naming and referencing shares, directories, files, and metadata and What are file path length limits?.
At 234, <name>.exe.runfiles_manifest is 234 + 22 = 256 characters, one over the limit (233 lands exactly on the 255 boundary).
In short, that's a different limit than the MAX_PATH one this test targets.

=> landed on splitting the length across both the package directory and the target name instead (_130_chars, to make the length self-explanatory in the spirit of your suggestion), so the overall runfiles path still exceeds MAX_PATH while each individual path component stays comfortably under the 255-char ceiling.

[fmeum]

@bazel-io fork 9.3.0

[meteorcloudy]

Thanks!