Response files issues and long path support

[Kojoley]

1. response-file=auto doesn't always use response files when it should, it probably does not count the compiler path in estimation?
2. A resulting path still can exceed the limits and b2 will fail with undescriptive message:

   [errno 2] failed to write output file '../../../bin.v2/libs/thread/test/test_condition_timed_wait_times_out.test/emscripten-3.1.37/release/exception-handling-on-js/link-static/target-os-unknown/threading-multi/visibility-hidden/test_condition_timed_wait_times_out.o.rsp': No such file or directory
   

3. A better fix seems to be to implement long path support https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry but it requires to use Unicode WinAPI.

[grafikrobot]

1. Correct it's still possible to have too long paths as the compiler can't be part of the calculations for executed commands. And it can't be because the execution can happen in some random shell which B2 can't interpret ahead of time to determine a more accurate answer to how long the command like is. Hence, we guess, with an arbitrary padding.

2. I guess the error message could be improved.

3. Even if we did that, and managed to write the response file, how would that help the shell? As the path would be too long for the shell also.

[Kojoley]

3. Even if we did that, and managed to write the response file, how would that help the shell? As the path would be too long for the shell also.

https://learn.microsoft.com/en-us/troubleshoot/windows-client/shell-experience/command-line-string-limitation

The maximum length of the string that you can use at the command prompt is 8191 characters.

That's since WinXP, on Win2000 it was 2047 which is still longer that 259.