std.fs: support Lock.none on Windows

[DivergentClouds]

Fixes #18430. Borrows code from #18566.

I also made std.windows.LockFile and std.windows.UnlockFile use the relevant explicit error set.

The doc comments and Windows API for File.lock File.tryLock have been changed to match the POSIX implimentation.

[squeek502]

Looks good, thanks for getting this fixed!

[DivergentClouds]

I apologize for the early requested review btw, I don't know how that happened

[alexrp]

Should this change also be made in unlock()?

[squeek502]

unlock can't return an error.

[alexrp]

Then it seems questionable to me that we're doing it here. If we're worried that the OS might become able to return an error here in the future, the same concern surely applies to unlock()? Are we just crossing our fingers and hoping that such an error will be safe to ignore in unlock()?

[squeek502]

Are we just crossing our fingers and hoping that such an error will be safe to ignore in unlock()?

I think so; same sort of thing with File.close. I agree that it seems strange for unlock, not sure that should really count as "resource deallocation."

FWIW, there's exactly one instance of File.unlock in a defer that I could find:

zig/lib/std/crypto/tls/Client.zig

Lines 1512 to 1513 in 5b4759b

	const locked = if (key_log_file.lock(.exclusive)) |_| true else |_| false;
	defer if (locked) key_log_file.unlock();

[alexrp]

I guess this isn't strictly related to this PR, and I might just be showing my ignorance, but I don't understand why file.lock(.none) is even a thing. Why not just file.unlock()?