Add tests for AsyncContext (Stage 2)

[andreubotella]

See https://github.com/tc39/proposal-async-context.

[andreubotella]

The tests in built-ins/AsyncContext/context-propagation/* are really tests that the changes to the HostMakeJobCallback and HostCallJobCallback host hooks are indeed reflected in the built-in APIs that use those hooks. Maybe they should be moved to those APIs' folders.

Also, built-ins/AsyncContext/context-propagation/generators.js currently tests a behavior that was agreed to in tc39/proposal-async-context#18 but that hasn't yet been changed in the spec text.

[caitp]

disclaimer: I may be missing some adjustments to generators in https://tc39.es/proposal-async-context/, but at a glance I wasn't able to find anything yet.

[jridgewell]

I've only reviewed the Snapshot cases so far, but a few more cases we could add:

• snapshot.run() uses undefined this context
• snapshot.run() restores previous context after abrupt throw

[jridgewell]

Well this wasn't intentional. I was just trying to avoid the length args, and it looked like LengthOfArrayLike did everything I wanted. Do we want to define this more rigorously?

[andreubotella]

I don't really care one way or the other, but Function.prototype.bind checks whether the length is a number before calling ToIntegerOrInfinity(), and if it isn't one it uses 0 rather than converting to a number.

Also, now that I look at it in some more detail, I realize that bind also checks HasOwnProperty before doing Get, whereas the wrap spec only does Get, so this might affect proxies. When we settle on this (one way or the other), we should also test it.

In any case, spec-wise the ShadowRealm proposal adds a CopyNameAndLength AO to share the behavior between bind and ShadowRealm wrapped functions. If we decide to have the same behavior as bind, it'd be better to just use that if we can.

[andreubotella]

I've updated the tests to the behavior CopyNameAndLength has. PTAL.