Switch maplike/setlike to use infra maps and sets

[tabatkins]

Fixes #254, fixes #824.

This PR switches maplike and setlike interfaces from using a [[BackingMap]]/[[BackingSet]] ES Map/Set to use an Infra map/set instead. As explained in #254 and #824, this makes the interfaces vastly easier to work with in spec-ese (you can directly manipulate an Infra map/set, rather than having to carefully perform the ES algo dance) , and removes some underdefined behavior (as currently defined, the algorithms look up and utilize the equivalent methods on Map.prototype and Set.prototype, which can be author-supplied).

Unless the author is relying on the "replace the Map.prototype methods" behavior (I haven't tested if impls actually allow this, in any case), this change should be undetectable, and just result in specs using maplike or setlike interfaces having an easier, better-defined time manipulating them.

Progress:

• Switched maplike and setlike to use an Infra map/set instead of a [[BackingMap]]/[[BackingSet]]
• Switched @@iterator to go over the infra map/set (but still return an iterator with the right prototype)
• Switch the rest of the Map methods to use the infra map
• Switch the rest of the Set methods to use the Infra set
• Moved the maplike/setlike @@iterator and forEach methods to live with the rest of their methods, rather than being in their own section
• Add verbage for "map setting steps"/etc for specs to use when defining custom behavior, a la "getter steps"

---

Preview | Diff

[tabatkins]

Ugh, I didn't push all my latest commits from my work machine. This is even more WIP than intended; you'll have to wait for tomorrow to actually see my current progress.

[tabatkins]

Okay, current progress is up and now matches the task list as I have represented it. Review would be nice, but I'll continue working on this without waiting.

[domenic]

Generally looks like it's on the right track; very nice work.

I only left a few substantive comments. I think there are some editorial things but we can do those in a final pass. One more-pervasive editorial thing you might want to get done earlier is to use "string" instead of "string" for strings.

[tabatkins]

Okay, finished the work I wanted to do, and addressed @domenic's editorial concerns they've raised so far. This PR is ready for proper review now.

I'm putting off defining "map setting steps"/etc; the text already defines that specs that want to provide their own set/delete/etc should just provide normal IDL methods of those names, so that should suffice.

I'd like to, probably in a follow-on issue, define all these built-ins in terms of the existing "create an operation function" algo, as that does all the nice setup that I'm currently doing by hand in each of the definitions, but that probably requires rejiggering the whole thing into imperative style. (I was gonna write an abstraction algo that folded away most of the boilerplate, but it turns out that "create an operation function" is that abstraction algo.) The current style is how the spec currently defines these operations, so keeping it as-is will at least not make things worse for now.

[domenic]

I didn't do a full review of setlike but there might be some stuff to copy over.

[domenic]

This round of editorial fixes seems likely final-ish...

[tabatkins]

Oof, sorry about the lingering copy-paste errors I still had.

[domenic]

LGTM. @EdgarChen do you want to take a look? I feel like I understand the map/set/infra parts of the Web IDL spec pretty well but as editor you should definitely get a chance to weigh in if you want :)

[EdgarChen]

I took a look and it looks good to me. Thanks for all your works!

[Liamolucko]

This PR changed the setlike add method to return the value that was added to the setlike object instead of the object itself. Was that an accident?

[TimothyGu]

@tabatkins Can you check the comment above?

[annevk]

When PRs or issues are closed, please always file a follow-up. I've taken care of it this time around: #1268.