Remove the api package to use concrete common types

[ankur22]

Feature Description

In Go, generally, interfaces are small and focused, as well as defined where they're being used. This also helps in testing, where we can define smaller focused interfaces which only mock methods that are used by the test, rather than a large interface where everything needs to be mocked even if majority of the methods aren't being used by the test.

The api package was useful when we required the concrete types to comply with the interface since we were returning the interfaces to the goja layer directly. E.g.:

// Ensure Browser implements the EventEmitter and Browser interfaces.
var (
	_ EventEmitter = &Browser{}
	_ api.Browser  = &Browser{}
)

Now that we're working with the mapping layer which explicitly maps the implementation to a goja type, this api compliance requirement is no longer required.

When working on recent investigative issues, we've found that this interface api compliance has become a hinderance.

This issue is too explore whether we can remove the api package and what the consequences of that would be. Something to consider are:

• Is is straight forward to find and replace the interface type with the concrete type?
• How the testing of the mapping layer is affected.
• Will the removal affect future work when working with other web browser?

POC

https://github.com/grafana/xk6-browser/commits/refactor/api-package-poc

---

Primary tasks

Beta Give feedback

1. Refactor integration test browser #935
   productivity refactor tests +3
   
2. Remove the api package #1055
   productivity refactor +2
   
3. Refactor the API interfaces to concrete types #1057
   productivity refactor +2
   

#1055: Remove the api package

Beta Give feedback

1. Postfix the api types with API
2. Move the api types into the common pkg
3. Remove the api pkg for good

#1057: Refactor the common API types to concrete

Beta Give feedback

1. Remove the common pkg API type dependencies
2. Use only concrete types throughout the module
3. Move the interfaces into the mapping layer and unexport

Already existing or connected issues / PRs (optional)

Related issues:

• Separate Sobek and k6 logic from the module logic #271