Potentially replace DefaultCompiler

[na--]

This commit added dumb mutex-based synchronization the Compiler's Transform() method. That was necessary because the shared global DefaultCompiler instance was not thread safe.

We should benchmark this, but it would probably be better if instead of synchronizing a single compiler instance, we parse the babel JS source once (e.g. in an init() function), cache the result, remove DefaultCompiler and create new independent compiler instances wherever we want to use them.

[na--]

This is a bit altered since the changes in #658 - now instead of a DefaultCompiler there's a "constructor" with a sync.Once() call to initialize something a singleton-like Compiler instance.

But the above issue still stands - we have to check if having a single instance that uses simple locking for the transpiling (as it currently is) is better than caching and sharing the result of goja's Compile()/CompileAST() for the babel source and using that to initialize totally separate compilers. This shouldn't make much difference for production k6 usage, but it could greatly affect the test execution speed once they are more parallel (#537).

[na--]

I'm closing this because, as I mentioned in #2296 (comment), we plan to get rid of Babel completely eventually. It doesn't make sense to refactor it beforehand...