Add a switch to get around private key permission check on network share.

Summary of the new feature / enhancement

I need to use private key that is stored on a sambashare, but win32-openssh won't use it because it is owned by the samba user and not the user running the command. Relevant output of ssh -vvvT -i J:.ssh\ed25519 git@github.com:
debug3: Bad owner on J:/.ssh/ed25519
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'J:\.ssh\ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "J:\.ssh\ed25519": bad permissions

It looks like this lines 96 -99 here https://github.com/PowerShell/openssh-portable/blob/bdacf9868fe9e8024a5312861b7aaa6faba1821f/contrib/win32/win32compat/w32-sshfileperm.c#L96 have to do with this and it's intended to make sure only the user running the command has access to the private key.

The problem is, short of making a samba ad server and logging into the domain on the client (I don't know if there are any gotchas in the process that would still prevent the private key working), makes using private key on at least a samba share impossible. Even if the samba ad server solution works, it's still a large hassle for a largely artificial restriction.

I request a switch to allow insecure private key on network share. This request is probably out of scope for this project given this is intended behavior and upstream has made clear of this. But to be fair on Linux I could get around this by simply creating the user locally and using sudo/doas. I can't do this on Windows.

Interesting thing is if in WSL I do sudo mount -t drvfs J: /mnt/test and do ssh -vvvT -i J:.ssh\ed25519 git@github.com on the mount, the command is able to work flawlessly even though the actual folder is owned by a completely different user and permissions show as rwxrwxrwx. Unfortunately, I can't use a workaround using the drvfs mount because I need to account for symbolic link creation being accessible on the Windows host and vice versa which drvfs seems to have limitations with at the moment.

Proposed technical implementation details (optional)

No response

Start with contrib/win32/win32compat/w32-sshfileperm.c, especially lines 96-99 linked in the issue, and trace how the private-key permission check is invoked for network-share paths. Define the switch behavior and verify that an explicit opt-in permits the reported Samba-share case without changing the default protection.