Fixes #5612.

Summary

• wrap Windows path-related OS errors in the local backend when --local-nounc is enabled and the affected path is long
• preserve the original Windows error while adding context that the path may exceed a Windows path length limit
• avoid rejecting paths before the Windows APIs run, so systems with long path support enabled can still succeed

Reproduction notes

On my Windows test machine, LongPathsEnabled=1, and a non-UNC path of 292 UTF-16 code units succeeds for os.MkdirAll, rclone file.OpenFile, os.Stat, os.Chtimes, os.Remove, and os.Rename. So the patch no longer enforces MAX_PATH before calling the OS.

For path-related Windows failures I could reproduce:

• rclone file.OpenFile below an overlong component returns ERROR_PATH_NOT_FOUND (3), shown as The system cannot find the path specified.
• rclone file.OpenFile with an overlong final component returns ERROR_INVALID_NAME (123)
• os.MkdirAll with an overlong component returns ERROR_INVALID_NAME (123)

The original issue/forum report mentions the localized equivalent of The system cannot find the path specified, so this wraps ERROR_PATH_NOT_FOUND and the related path-length/name errors only when --local-nounc is set and the path is long.

Tests

• go test ./backend/local -run 'Test(WrapWindowsLongPathError|RmdirWindows|CleanWindows|IsDiskFullError|UpdateFatalIfNoSpace)' -count=1
• GOOS=linux GOARCH=amd64 go test -c ./backend/local -o NUL

I also ran go test ./backend/local -count=1 on Windows. It currently fails in existing symlink tests because this account does not have the Windows privilege to create symlinks (A required privilege is not held by the client).