Allow multimaps (or directly support them)

[tabatkins]

There are a few places on the platform implementing the "multi-map" pattern, where:

1. the underlying values are lists of something
2. get() only returns the first value in the list
3. set() becomes set(key, ...values)
4. getAll(key) is added, returning the list
5. append(key, ...values) is added, adding/creating to the list

This allows users of the interface to pretend that it's a normal map with only a single value per key, but also properly interact with it as containing multiple values, without having to always treat it like a list. (This is currently used by URLSearchParams and StylePropertyMap.)

Problem is that maplike<> doesn't allow you to override get() to have the correct behavior.

---

We should probably actually define multimaps officially, because right now URL and TypedOM use slightly different definitions - URL doesn't make set() or append() n-ary, and just uses iterable<> (so that it can interweave different values for a single key with values for other keys; ?one=foo&two=bar&one=baz is important to preserve and reflect). I think this means we'd actually need two multimap forms - one for map<key, list<val>> (StylePropertyMap) and one for list<(key,val)> (URLSearchParams).

[tabatkins]

Discussing with @domenic in IRC illuminates some more differences between the two forms - list<(key, val)> semantics will usually want to set() in-place, like URLSearchParams does, deleting all the entries beyond the first, and with that, making set() n-ary doesn't make very much sense. (Tho append() should still be n-ary.)

On the other hand, for the map<key, list<val>> semantics, regardless of whether you set in-place or do a remove/append, it makes sense to set() multiple values at once.