Add iterable methods for FormData, Headers, and URLSearchParams

[ispivey]

I looked through https://github.com/microsoft/TypeScript/blob/master/lib/lib.dom.iterable.d.ts and I think these are the three interfaces we implement in the Workers API that have iterable methods that should be added.

I tested by transpiling some of my draft TypeScript templates in ispivey/template-registry#1 which use the FormData iterable methods; Headers and URLSearchParams are untested but I did verify that these are all implemented in the runtime.

Fixes #25 .

[harrishancock]

While the linked issue is a bit over my head, this looks great.

[ispivey]

@harrishancock to make the linked issue slightly more specific and concrete (not that you need to follow it, but explaining it helps me make sure I get it):

1. TypeScript supplies libraries that specify the interface for "Web Workers", lib.webworker.d.ts, and the DOM, lib.dom.d.ts
2. When you import both, you observe errors like node_modules/typescript/lib/lib.webworker.d.ts(1648,13): error TS2403: Subsequent variable declarations must have the same type. Variable 'FormData' must be of type '{ new (form?: HTMLFormElement): FormData; prototype: FormData; }', but here has type '{ new (): FormData; prototype: FormData; }'.
3. This is because the lib.dom.d.ts definition of the FormData constructor and the lib.webworker.d.ts definition of the FormData constructor are different.

Hence, my conclusion that users can't use both the DOM and WebWorker type definition libraries at the same time.

This matters because, for reasons I don't understand yet, the "iterable" methods for types like FormData (entries, keys, values) are only defined in a separate lib.dom.iterable.d.ts library (DOM.Iterable), which itself depends on lib.dom.d.ts (DOM).

So you can either use WebWorker's FormData without iterable methods, or use DOM and DOM.Iterable and have access to FormData's iterable methods, but then you lose the rest of the Service Worker API.

This change lets us use the iterable methods while using the WebWorker libraries, as we wait on TypeScript to do something about it in their upstream libs.

[1000hz]

Looks great. This seems like the best approach we can take.

I took another look at dom.iterable.d.ts to see if there was anything else from there we might need to pull over and saw this overload for Cache.prototype.addAll(). Not sure, but it seems we'd want to include that as well.

[ispivey]

@1000hz thanks! I’ll make sure we implement that; if so I’ll add it to this PR before merging.

[harrishancock]

@ispivey thanks for explaining the issue -- that makes sense now.

Also, sadly we do not implement Cache.addAll().