Behaviour of concurrent calls to IndexInput#clone is unclear [LUCENE-9138]

I think this is a documentation issue, rather than anything actually wrong, but need expert guidance to propose a fix.

The Javadocs for `IndexInput#clone` warn that it is not thread safe:

- <p>This method is NOT thread safe, so if the current \{`@code` IndexInput}
- is being used by one thread while \{`@code` clone} is called by another,
- disaster could strike.
\*/
`@Override`
public IndexInput clone() {

However, there are places where `clone()` may be called concurrently. For instance I believe `SegmentReader#getFieldsReader` clones an `IndexInput` and requires no extra synchronization. I think this comment is supposed to mean that you should not `clone()` an `IndexInput` while you're _reading or seeking from it_ concurrently, but the precise guarantees aren't totally clear.

 
Furthermore there's no mention of the threadsafety of `slice()` and there seem to be similar concurrent usages of it in e.g. `Lucene80DocValuesProducer`. Does this have the same guarantees as `clone()`?

---
Migrated from [LUCENE-9138](https://issues.apache.org/jira/browse/LUCENE-9138) by David Turner, updated Jan 17 2020

Start with the IndexInput#clone Javadoc and inspect the concurrent usages mentioned in SegmentReader#getFieldsReader and Lucene80DocValuesProducer. Determine the intended thread-safety guarantees for clone() and slice(), then clarify the relevant Javadocs so the documented behavior matches those usages.

Written by the indexing model from the issue text.