Fix TrinoOutputFile.create javadoc

[findepi]

No description provided.

[wendigo]

dangling f

[findepi]

thanks @wendigo , fixed

[oneonestar]

The semantics are slightly different. This won't affect how caller use create() because currently we don't have a way to check is the underlying FS support it or not. However, this will affect how someone who tried to implement a FS in the future.

// Before
if (FS support create file exclusively and atomically) {
    create file exclusively and atomically
}
else {
    createOrOverwrite()
}

// After
if (FS support create file exclusively and atomically) {
    create file exclusively, could fail or overwriting an existing file
}
else {
    createOrOverwrite()
}

I went thought all the implementations and they all follow the former semantic. I don't think it is necessary to loose the restriction. I don't recommend this change.

HDFS: atomic (https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/filesystem/introduction.html#Core_Expectations_of_a_Hadoop_Compatible_FileSystem)
LocalFS: atomic, backed by Files.newOutputStream(StandardOpenOption.CREATE_NEW) 
MemoryFS: atomic, backed by ConcurrentHashMap.putIfAbsent()
Azure: atomic, backed by setIfNoneMatch(HeaderConstants.ETAG_WILDCARD))
GCS: atomic, backed by BlobTargetOption.doesNotExist()
S3: Non-atomic

[findepi]

@oneonestar i think i am correcting the first sentence of the javadoc only.
First sentence should be correct, currently it's not, which is apparent when all javadoc is read.