Worker: use real runtime in unit tests

[josephjclark]

Closes #486

The worker at the moment uses a mock runtime engine to test against.

This is quite reasonable because we don't want to be spinning up loads of threads while unit testing worker functions. It's overkill.

Previously the engine mock did include it's own fake little runtime with very limited functionality. But there are two big problems with this:

1. Job code passed into worker functions doesn't look like job code. It looks weird because it's written to run against the mock
2. Events and errors coming out of the runtime are quite complex, and the worker needs to be able to run real and sophisticated workflows to test certain behaviours. It's too hard to simulate this in a mock, so I'm using real code instead.

The mock engine does not autoinstall. It will call the credentials resolver. It will do a sort of fake compilation of jobs - it won't download an adaptor and do real compilation, but it will wrap the fn() call in an export default [fn] wrapper for compatability. It also injects some "fake" adaptor functions into the job scope.

Globals

To make this work I'm pulling in some old code from #303. This allows us to set globals in the runtime scope.

This functionality is not exposed to the CLI or the Worker. Just the mock worker .

[josephjclark]

As a result of using the new runtime, I can now write really sophisticated tests like this, which deeply test a) how the runtime handles complex Attempts and b) how the worker maps runtime events to Lightning events.

If I had this test two weeks ago, I'd have skipped over a lot of hurt this week!

This proves the value of this work, in the next couple of weeks I'll be building more more complex tests like this.