[FeatureRequest] Implement FileSystemProvider file channels

[iils-jschmidt]

For example SMBFileSystemProvider currently does not override FileSystemProvider.newFileChannel() and generates a UnsupportedOperationException.

I think this could be implemented using SmbConstants.FILE_NO_SHARE "somehow".

[HannesWell]

The main-motivation of the request is to be able to perform multiple read/write operations on a file while holding the file's lock to ensure they are 'atomic'.

For a local file one would create a FileChannel and obtain a FileLock from it. For example like:

Path file = ... // obtain the Path of the file to operate on
Set<StandardOpenOption> rwc = Set.of(StandardOpenOption.READ, StandardOpenOption.WRITE, StandardOpenOption.CREATE);
try (FileChannel channel = FileChannel.open(file, rwc); FileLock lock = channel.lock()) {
	readAndWriteFromSeekableByteChannel(channel);
}

This does not work for a Path that uses the SMBFileSystem because the SMBFileSystemProvider does not implement FileSystemProvider.newFileChannel() as mentioned initially.
It would be of course nice, if you would implement the corresponding methods but I assume this will require a medium/large amount of work.

A much simpler solution for this use-case would be to add support for the ExtendedOpenOption from the package com.sun.nio.file to SMBFileSystemProvider.newByteChannel(). Those options would only have to be mapped to corresponding combinations of SmbConstants and then passed to the SeekableSMBByteChannel and further to SmbRandomAccessFile.

Instead of using enum constants from com.sun.nio.file (where I'm not sure if this might become strongly hidden in future Java-versions) that have opposite meaning, it could be simpler to create own implementations of OpenOption that map 1:1 to the corresponding SmbConstants.
So in the end one could call the following (or similar) to obtain a SeekableByteChannel that is locked while being open:

SeekableByteChannel channel = Files.newByteChannel(lockFile, SmbOpenOption.FILE_NO_SHARE);

[HannesWell]

@ppanopticon would you appreciate a PR that implements what I have described?