Refactor the module structure for the new executors

[na--]

This discussion is a nice starting point for what's currently suboptimal: #1007 (comment)

I also noticed that the lib package depends on the js/compiler package... go list -f '{{ join .Imports "\n" }}' github.com/loadimpact/k6/lib | sort produces:

...
github.com/loadimpact/k6/js/compiler
github.com/loadimpact/k6/lib/fsext
github.com/loadimpact/k6/lib/types
github.com/loadimpact/k6/loader
github.com/loadimpact/k6/stats
github.com/loadimpact/k6/ui/pb
...

it's not related to the new executors, but this shouldn't be the case

[na--]

Some of the tests of the API (and probably other modules as well) are currently structured in such a way that they import the js package: https://github.com/loadimpact/k6/blob/298cf6bfab04d64392db34872240aca0f96c3e78/api/v1/setup_teardown_routes_test.go#L37

This would cause any library that also imports them to include things like goja and core.js, which is probably not what we want... 🤦‍♂️ We can instead use different package names for these tests, for example v1_test.

[mstoykov]

hm ... I think that it probably won't require the js package as it is only in the test, but I could be wrong ...

[oleiade]

We have recently discussed this issue in our backlog grooming session. We agreed that if the specific issue reported here: the lib package importing the js module, we should close.

I just verified on master and it seems to be the case indeed. Closing this. Feel free to reopen in the future if you believe this issue is still relevant regardless.