[FEATURE][Enhancement][Calcite] Support batch friendly Limit operator

Is your feature request related to a problem?
In Calcite, EnumerableLimit is implemented by using linq4j take.

  public static <TSource> Enumerable<TSource> take(Enumerable<TSource> source,
      final int count) {
    return takeWhile(
        source, (v1, v2) -> {
          // Count is 1-based
          return v2 < count;
        });
  }

However, the current implementation has to rely on the current row to decide whether the enumerator is able to move next, although it don't have to. For Limit, only the current row count is enough for predication.

Hence, it has downgrade when we have to fetch the next batch to provide the current row. And the downgrade will be amplified if there is a low-pass-rate filter operator after our scan operator, in which case we may have to fetch many batches even the whole index.

What solution would you like?
A clear and concise description of what you want to happen.

What alternatives have you considered?
A clear and concise description of any alternative solutions or features you've considered.

Do you have any additional context?
Add any other context or screenshots about the feature request here.

Start by tracing Calcite's EnumerableLimit implementation and the linq4j take method shown in the issue. Clarify how batch advancement should work without relying on the current row, then identify the relevant execution tests. Done means the Limit operator supports the requested batch-friendly behavior without the described extra batch fetches.