feat(java): expose core reader tuning options in Java bindings

[jihuayu]

Which issue does this PR close?

Closes #8252.

Rationale for this change

Java input streams cannot configure the core reader’s chunking, concurrency, or prefetching. Exposing these controls separately from ReadOptions keeps reader execution settings distinct from the logical read range.

Considering that ReadOptions and ReaderOptions are separate abstractions in OpenDAL, I think we should introduce a new ReaderOptions configuration in the Java binding instead of extending ReadOptions with reader-specific controls.

gap is not exposed because Java’s InputStream uses the core’s into_bytes_iterator(range) to read a single continuous range. The option only affects range merging in Reader::fetch, which the Java binding does not currently expose.

What changes are included in this PR?

• Add ReaderOptions with concurrent, chunk, prefetch, and contentLengthHint.
• Add createInputStream(path, readOptions, readerOptions) and map its execution settings to core options through JNI.
• Validate option values and use checked numeric conversions.
• Add mapping and stream behavior tests, and document option semantics and resource usage.

Are there any user-facing changes?

Yes. Java callers can enable chunked reads by setting a positive chunk and tune internal request concurrency and buffering. Setting concurrent alone does not enable concurrent range reads.

Existing overloads and constructors remain available with their default unchunked streaming behavior. Invalid reader option values produce OpenDALException with code ConfigInvalid when the stream is created.

AI Usage Statement

I used GPT-6 to complete the implementation and to write the tests and documentation. I personally reviewed all of the code.

[Xuanwo]

ReadOptions overlaps ReaderOptions. It seems we should just accept ReaderOptions here?