refactor: Simplify NLJ re-scans with ReplayableStreamSource

[2010YOUY01]

Which issue does this PR close?

• Closes #.

Rationale for this change

Background

#21448 introduced memory-limited execution for NLJ (thanks to @viirya).

The idea is:

1. Load the build (left) side of the NLJ until the memory limit is reached.
2. Probe the right side and complete the join for the current buffered build-side chunk.
3. Load the next chunk of the build side and repeat the right-side scan until all data is processed.

To support repeated probing of the right side, input batches are spilled to disk during the first pass. In subsequent passes, input is read directly from the spill. This avoids re-evaluating potentially expensive pipelines (e.g., Parquet decoding + filtering), making repeated probes both memory-efficient and fast.

This PR

This PR extracts the spill-backed replayable stream into a separate module to simplify the NLJ implementation.

Although the lines of code increase, the new module provides a clearer interface and I think it's easier to maintain.

Additionally, this utility may be useful elsewhere. I have seen a similar pattern in SedonaDB for memory-limited spatial joins.

What changes are included in this PR?

• Introducing ReplayableStreamSource for the above purpose
• Refactor NLJ logic with ReplayableStreamSource

Are these changes tested?

UTs, also covered by existing memory-limited NLJ test

Are there any user-facing changes?

No

[martin-g]

Thanks!

Few nitpicks which you could just ignore!