Browser v2: Async APIs

[sniku]

### Migrate to Async

### Nice to have
- [ ] grafana/jslib.k6.io#125

### Migration is complete - Document the changes

### Done Done
- [ ] grafana/xk6-browser#1362
- [ ] grafana/xk6-browser#1302
- [ ] grafana/xk6-browser#683
- [ ] grafana/xk6-browser#463
- [ ] grafana/xk6-browser#439
- [ ] grafana/xk6-browser#440
- [ ] grafana/xk6-browser#1251
- [ ] grafana/xk6-browser#583
- [ ] grafana/xk6-browser#1294
- [ ] grafana/xk6-browser#1295
- [ ] grafana/xk6-browser#1296
- [ ] grafana/xk6-browser#1303
- [ ] grafana/xk6-browser#1304
- [ ] grafana/xk6-browser#1305
- [ ] grafana/xk6-browser#1306
- [ ] grafana/xk6-browser#1307
- [ ] grafana/xk6-browser#1308
- [ ] grafana/xk6-browser#1309
- [ ] grafana/xk6-browser#1359
- [ ] grafana/xk6-browser#1321
- [ ] grafana/xk6-browser#1298
- [ ] grafana/k6-docs#1600

---

What

This issue has been repurposed to initiate and follow the progress of migrating most of the browser APIs to async (promise based).

A recent example is this issue where touchscreen.tap was migrated to async:

From:

page.touchscreen.tap(...);

To:

await page.touchscreen.tap(...);

Why

1. Most browser APIs use some form of long-running IO operation (networking) to perform the requested action on the web browser against the website under test. We need to avoid blocking JavaScript's runtime event loop for such operations.
2. We're going to add more asynchronous event-based APIs (such as page.on) that our current synchronous APIs would block.
3. To align with how developers expect to work with JavaScript APIs.
4. To have better compatibility with Playwright.

How

We have detailed exactly which APIs will most likely need to be migrated across in the comment within this issue. For most of the APIs we can take a look at the comment and migrate the APIs that are listed there. It's worth noting that it's still best to double check whether the API needs to be migrated especially ones which k6 browser implements but aren't provided by Playwright, for example page.throttleCPU.

NOT Implemented In PW

If an API is not implemented in PW, then you should be able to answer yes to one of the questions in the list below to determine whether it should be async or not, for example browser.context is not in PW, and it doesn't do any IO or long running tasks, therefore it can stay as a synchronous API.

1. Does the API perform a network call or other IO operations, this includes a CDP request to Chrome?
2. Does the API perform long running task?

Implemented in PW

Is the API in the list in this comment and is implemented in PW?

If the answer is yes, then it can be migrated to async.

Goja, docs and type defs

Initially we're only interested in moving the API to async, and not worrying about goja, doc and type definitions updates. Doc and type definition updates will be deferred to after the implementation work and before the release. We're hoping that the goja refactoring/abstraction work can also be shifted to a later point, but we may find that some APIs will also need goja to be refactored out of them to prevent panics and race conditions.