feat: Resolve coordinate system semantics for input and output positions

[nvictus]

This PR adds the ability to honor genomic coordinate system semantics in the way input query ranges are interpreted, and the way output positions (namely, start positions) are returned. Resolves #114.

Coordinate systems

There are two "coordinate system" conventions in genomics:

1. Zero-based, half-open (i.e. left-inclusive, right-exclusive) -- aka "zero-based start, one-based end". [1000, 2000)
2. One-based, closed (i.e. left-inclusive, right-inclusive) -- aka "one-based start, one-based end". [1001, 2000]

We introduce shorthands for these in Python: "01" and "11". And every scanner is now coordinate-system aware in its output, defaulting to a format family-"native" system.

Range notation

We further support 3 range string notations:

1. Ambiguous UCSC notation, interpreted using the scanner's registered coordinate system. chr1:10,000-20,000
2. Explicit "bracket notation" for 01-semantics: chr1:[10_000,20_000)
3. Explicit "bracket notation" for 11-semantics: chr1:[10_001,20_001]

Thousands separators , and _ are supported (only the latter in bracket notation).

Example

# default for SAM/BAM/CRAM is 11
df = ox.from_bam("example.bam").regions("chr3:10,001-20,000").pl()

# return 01 output and interpret query regions as 01
df = ox.from_bam("example.bam", coords="01").regions("chr3:10,000-20,000").pl()

# return 01 output, pass in 11 input
df = ox.from_bam("example.bam", coords="01").regions("chr3:[10001,20000]").pl()

Malformatted files

This feature alone does not solve the problem malformatted files, most often observed with text formats. BED is natively 01, but many BED-like files in the wild contain intervals with 1-based starts. Likewise, GTF is supposed to be 11, but many may use 0-based starts. If one knows the start positions in a file don't match what the format natively expects, one has to choose a coordinate system interpretation and increment or decrement the start positions accordingly to correct them.

Changes

• Add a CoordSystem enum (OneClosed / ZeroHalfOpen) that controls how start positions are represented in output Arrow batches and how user-supplied query regions are interpreted.

• Add an oxbow::Region type with coordinate-system-aware parsing, supporting ambiguous UCSC notation (interpreted using a CoordSystem) and an explicit bracket notation.

• Each format defaults to its native coordinate convention (1-based for SAM/BAM/CRAM, VCF/BCF, GFF/GTF, FASTA; 0-based for BED, BigBed, BigWig) but callers can request either system explicitly via a coords parameter.

• All scanner scan_query methods now accept oxbow::Region instead of noodles::core::Region, converting internally.

• Python API exposes coords as literals ("01", "11") on all DataSource classes and from_* factory functions, as well as pyo3 scanner classes.

• pyo3 read_* functions and R bindings updated to use format-native coordinate systems.

[conradbzura]

Region { start: 5000, end: None } displays as chr1:[5000,), but try_parse_bracket can’t parse an empty end — it splits on , and fails "".parse::<u64>(). Because try_parse_bracket returns Some(Err(…)) instead of None, the UCSC fallback path is never reached, so FromStr roundtrips break for any open-ended region with an explicit start.

Either extend bracket parsing to accept [start,) as open-ended, or have Display emit UCSC notation for the unbounded case (e.g., a 0-based chr1:5001- under the default OneClosed assumption).

[conradbzura]

saturating_sub(1) correctly avoids wrapping to u64::MAX, but it also silently accepts start = 0, which isn’t a valid 1-based position. In UCSC mode with OneClosed, chr1:0-100 quietly normalizes to start = 0 (0-based) — the user gets a plausible-looking result from an invalid input. The same applies to bracket notation [0,100] at line 236.

A guard like if start == 0 { return Err(invalid_input("1-based position must be >= 1")) } before the subtraction would catch the mistake early.

[conradbzura]

@nvictus sorry I'm a little late, but noted a couple of things.