Proposes (again) returning multiple adapters in response to an adapter request.

See #524 for previous discussion and rationale. (But note this PR differs in some small ways.)

• requestAdapters is not any more prone to fingerprinting. The UA can choose to put whichever adapters it wants in the list. Any adapters returned from it could have been found by searching the space of possible requestAdapter calls.
• Many applications would end up trying to get every adapter they can find (by searching the space ...) and then using their own logic to pick among them. This prevents apps from needing that pattern.
• requestAdapters still allows an easy default: e.g. ask for "low-power", then get adapter [0].
• requestAdapter is hostile to any situation where the UA does want to give a little more trust to the app, perhaps Electron, Node, or even installed PWAs.

It is now our opinion that this is the right solution. Like #1273, it's a highly flexible API that allows UAs to do device bucketing ahead of time, or even lazily during accesses to the returned array. Most apps will use item [0], and such behavior can be observed by the UA if needed.

This design should avoid any pitfalls that would cause an otherwise well-written app (which chooses adapters properly on various hardware configurations, which is not hard) to fail on a UA which chooses to limit the set of returned adapters in any way; such a response would look equivalent to some other reasonable hardware configuration (e.g. a 2-gpu system looking like a 1-gpu system).

New in this PR, it requires specific predictable behavior, so that developers don't have to worry about some UAs e.g. requiring multiple calls to requestAdapters where others would not. (powerPreference must not affect the set of adapters returned, only the order.) I have further changes to propose after this that will require more predictable behavior for when device creation should fail, as well.

Preview | Diff