Spec should be clearer than a `Promise<T>` argument also accepts `T` objects

[tabatkins]

What is the issue with the Web IDL Standard?

As far as I can tell, when an argument is of type Promise<T>, no verification is done on the value itself. Instead, when such an argument passes from JS into IDL, the algorithm just wraps the value in a new promise capability (which absorbs a passed promise, but also absorbs arbitrary thenables, and in fact any value at all). (This is presumably why it's not allowed to put Promise<> in a union, because it already absorbs all possible input types and thus isn't distinguishable from anything.)

This implies a few things that I think are useful for spec authors to know, neither of which are spelled out in the spec:

1. Authors can automatically pass T values to any Promise<T> argument.
2. Authors can also pass non-T values to any Promise<T> argument, so the function's algorithm needs to manually verify that it's the right type when responding to the promise.

I'm happy to PR some Note text, if y'all agree this is worth fixing.

(Context: a Googler spec author was asking how they should write their IDL to accept both a T and Promise<T> for an argument.)

[mkruisselbrink]

Re 2, I think the react to a Promise<T> algorithm and similar webidl algorithms do a lot of the heavy lifting for making sure you actually get a T. But yeah, any algorithm ingesting a promise needs to do something to handle the promise rejecting or resolving with an unexpected type.

[tabatkins]

Ah thanks, yeah, react to a promise works fine for ensuring you actually get a T out (anything else will either convert to a T via the standard rules, or throw an error, and I don't believe spec text needs to handle errors explicitly; it'll get auto-caught by the IDL machinery and cause a rejected promise).

So yeah, it's just the fact that T can be passed to a promise<T> argument that should be spelled out (in a note).