Implement ES2025 Iterator constructor

[anivar]

Iterator Infrastructure Improvements

This PR adds robust iterator handling infrastructure to Rhino with three new utility classes that solve Context safety and architectural issues.

What's Added

IteratorOperations.java - Context-safe iterator utilities

• collectToArray() / collectToList() - Convert iterators to collections
• forEach() - Process iterator values with proper cleanup
• isIterable() / getIterator() - Iterator protocol helpers
• Key benefit: All methods take Context as parameter instead of capturing it (thread-safe)

ES6IteratorAdapter.java - Iterator.from() wrapper

• Wraps any iterator to inherit from Iterator.prototype
• Delegates all operations (next, return, properties) to wrapped iterator
• Enables proper prototype chain for Iterator.from() results

Enhanced IteratorLikeIterable.java - ECMAScript → Java bridge

• Handles ECMAScript iterator-like objects per spec
• Now uses IteratorOperations internally for Context safety
• Provides Java Iterable interface for Promise.all, Array.from, etc.
• Added Context-safe overloads: iterator(cx, scope), close(cx, scope)

Why This Matters

Context Safety: Rhino's multi-threaded environment requires careful Context handling. These utilities avoid the common bug of capturing Context in instance variables or closures.

Architecture: Clean separation between ECMAScript iterator protocol and Java's Iterable interface, enabling robust iterator support across Rhino's codebase.

Developer Experience: Consistent, reusable patterns for iterator handling that other contributors can safely use.

[gbrail]

Before we get farther on this -- can some of the other users of the project take a look at this feature and let me know how we should handle it? It's the first time we've added a feature flag for something as basic as iterator behavior AFAIK.

When we went through this before, we created VERSION_ECMASCRIPT and said that, in the future, we'd track the spec.

To me, that means that this feature should not have a feature flag, but should instead be invoked if the language version is VERSION_ECMASCRIPT.

Anyone else have an opinion on this?

[rbri]

can some of the other users of the project take a look at this feature and let me know how we should handle it?

@gbrail before have a serious look at this i like to have it in a good shape. During the last weeks is spend far too much time discussing the pr's having this garbarge test262.properties file.