Qbs cannot properly handle paths longer than MAX_PATH (260) characters in Windows

Note the documentation for max paths: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247.aspx#maxpath

Currently in qbs we bypass QFileInfo and use native APIs for obtaining some file information, presumably for performance reasons, as well as some other native API calls for functionality not provided by Qt.

However, we fail to prefix the input to these functions with "\\?\" and this will in some cases silently fail to acknowledge any paths greater than MAX_PATH (260) characters as existing. Qbs should properly prefix the path, and I wonder what terrible bugs have lurked as a result of this...

Note that QFileInfo has complex logic for dealing with paths to bypass the 260 problem.

A quick audit of the codebase reveals 4 offenders:

• FileInfo::isFileCaseCorrect - raw path passed to FindFirstFile
• FileInfo constructor - raw path passed to GetFileAttributesEx
• processNameByPid - MAX_PATH used in a buffer which is filled by a call to GetModuleFileNameEx
• windowsSystem32Path - MAX_PATH used in a buffer which is filled by a call to SHGetFolderPath

Presumably, we should pass correct "\\?\" prefix to any Win32 API functions to avoid this problem. We also must not use MAX_PATH at all. Presumably we should use the constant UNICODE_STRING_MAX_CHARS (32767) from winnt.h instead.

And possibly add the items noted in the documentation to the apps' manifests, so that the problem goes away automatically in the latest versions of Windows 10.