[js] Enable haxe for-in iteration of js.lib Map and Set

[haxiomic]

This enables using for-in on js.lib.Set, js.lib.Map and js.lib.Iterator;

Impact on Existing Code
None expected

For example, the following will now compile:

var set = new js.lib.Set();
set.add('A');
set.add('B');
set.add('C');

for (value in set) {
    trace(value);
}

var map = new js.lib.Map();
map.set('a', 1);
map.set('b', 2);
map.set('c', 3);

for (key => value in map) {
    trace('$key => $value');
}

For key-value iteration over a Set I've matched the behavior of haxe.ds.List

for (key => value in set) {
    trace('$key => $value');
}
// 0 => A
// 1 => B
// 2 => C

To iterate over a js.lib.Iterator requires using the HaxeIterator class:

using js.lib.HaxeIterator;
...

for (value in set.values()) {
    trace(value);
}

or alternatively

for (value in new js.lib.HaxeIterator(set.values())) {
    trace(value);
}

The generated code gets nicely inlined, for key-value iteration on map it looks something like

var jsIterator = map.entries();
var _this_lastStep = jsIterator.next();
while(!_this_lastStep.done) {
    var v2 = _this_lastStep.value;
    _this_lastStep = jsIterator.next();
    console.log("Main.hx", v2[0] + " => " + v2[1]);
}

[RealyUniqueName]

This is semantically wrong. It makes js.lib.Iterator a Haxe's Iterable.
The difference is the former could be iterated one time, while the latter could be iterated multiple times.
So js.lib.Iterator should behave like Haxe's Iterator, which means fields next():T and hasNext():Bool should be declared directly on js.lib.Iterator. But I don't think it's possible because ES6 Iterator already has next with a different signature.
Though, that's pretty convenient to have iterator() field on js.lib.Iterable :)

[haxiomic]

Yeah, I agree about the semantic issue, ideally we'd just have next():T and hasNext() on the abstract but I couldn't find a way around the collision with the ES6 next()

Maybe the solution here is to rename abstract Iterator to abstract Iterable and use that in Set and Map instead

[haxiomic]

To resolve the semantic issue, I've disabled iterating over js.lib.Iterator (now instead there's a class HaxeIterator and you have to manually convert it via new HaxeIterator(jsIterator))

But iterating over Set and Map will still work and is semantically sound

(I tried lots of approaches to try to resolve the semantic issue with iterating over js.lib.Iterator however I don't think it's possible to be fully correct here)

[haxiomic]

To enable js.lib.Iterator iteration you can do

using HaxeIterator;

Which avoids any semantic issues because js.lib.Iterator still can't unify with StdTypes.Iterable

[RealyUniqueName]

MapKvIterator and SetKvIterator are not needed. You can have inline function iterator() return new HaxeIterator(this.values() /* or this.entries() */) on both Map and Set

Edit: Sorry, SetKvIterator is actually required, because of key:index++ . But Maps iterator already returns a structure, which is compatible with Haxe's KeyValueIterator. Try it, please

[Aurel300]

Also the Kv abbreviation seems unnecessary, why not spell it out?

[haxiomic]

Thanks for reviewing @RealyUniqueName :), I've removed MapKvIterator (not sure why I thought I needed it in the first place 🙃)

It would be nice to have a @:using(HaxeIterator) on typedef Iterator so this works out of the box:

for (key in map.keys()) {
    ....
}

But that requires resolving #8188 so it's something I'll revisit in the future