feat: add lazy prime iterator API (primes_from, primes_upto)

[s-celles]

Add PrimeIterator{T, Up} unified parametric type with:

• primes_from(n) for ascending and
• primes_upto(n) for descending

lazy iteration over primes.

Fully composable with Base.Iterators (take, takewhile, zip, etc.).

Closes #176

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.40%. Comparing base (20a92a0) to head (7580f64).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #178      +/-   ##
==========================================
+ Coverage   93.08%   94.40%   +1.32%     
==========================================
  Files           2        2              
  Lines         463      483      +20     
==========================================
+ Hits          431      456      +25     
+ Misses         32       27       -5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[oscardssmith]

IMO API isn't quite what we want. By committing to an iterator API without an upfront size, we are unable to know whether the user will iterate it enough for a sieve to be worth it. I think the better API here is eachprime([lo,] hi) (matching our current primes API). By specifying a start and stop point, this API allows us to know whether we want to use a sieve or just to do separate isprime checks (presumably with some pre-sieving).

[s-celles]

That's a fair point, and eachprime([lo,] hi) is a cleaner fit for the sieve-vs-isprime decision since the interval width is known upfront at construction time.

I'd argue the two APIs are complementary rather than exclusive though. eachprime(lo, hi) is the right tool when the bounds are known - and it should definitely be the primary API. But there are legitimate use cases where no natural hi exists:

# find the first prime ≥ n satisfying an arbitrary predicate
first(p for p in primes_from(n) if p % 4 == 1)

# twin prime candidates — no upper bound
zip(primes_from(2), Iterators.drop(primes_from(2), 1))

For these, eachprime(lo, hi) doesn't help unless the caller artificially picks a hi - which defeats the purpose.

[oscardssmith]

That's fair. I feel like those use-cases likely should be written in terms of nextprime/prevprime since if you expose a PrimeIterator, people will use it (even if it is orders of magnitude less efficient for their use-case). Good API design is all about steering people towards APIs that will make their code efficient.