Skip setting last modified time when FS does not support it

When Maven resolver downloads a file and writes it to disk, it tries to set the last modified time on it. There are filesystems that do not support the "set last modified time" operation. In that case the operation will fail, and the Maven build will error out with a FileSystemException. Attached is (the last part of) such a stack track trace.

I encountered such a file system when running in a Kubernetes (Openshift actually, but that's Kubernetes based) cloud setup. I mapped the ~/.m2 directory to a Persistent Volume Claim so that files downloaded in one build are retained in the next build. I explicitly set the access mode to ReadWriteMany (a.k.a. RWX, a.k.a. Shared Access) so that multiple build nodes can use the same PVC. The PVC is provisioned by a `file.csi.azure.com` provisioner. And that translates to a file system that does not support setting the last modified time on a file. Thus the call to java.nio.file.Files.setLastModifiedTime(Path, FileTime) in org.eclipse.aether.transport.http.HttpTransporter.EntityGetter.handle(CloseableHttpResponse)org.eclipse.aether.transport.http.HttpTransporter.EntityGetter.handle(CloseableHttpResponse) comes crashing down.

There is no good way to query if the FS supports the call. So I resorted to wrapping the call in a `try .. catch` block. This seems to work. Maven downloads dependencies again, and my build progresses.