Guard against panics in VUs

[na--]

As demonstrated by #1153, it's possible that panics can crop up unexpectedly - from Go version updates in that case, but also from things like dependency updates or just simple bugs we inadvertently introduce. Given that in the k6 architecture each VU is semi-independent, if a panic occurs on a VU goroutine, we can probably try and stop its spread there and not abort the whole test run.

The potential problem with doing something like that is that k6 reuses VUs when ramping up and down. After #1007, it's also going to reuse VUs across executors. However, if a VU panics, it's likely in an unstable state, so we can't just reuse it... We'd need to re-initialize it or mark it as unstable, never to be used again. The second option would basically result in no-ops, which is far from ideal and will likely cause busy-looping in our looping-based executors, so re-initialization of the VU seems more appropriate... So, we should probably tackle this after #1007, given that we introduce a mid-test initialization of VUs there for the arrival-rate executors...

Also, it might be a good idea to track the number of panics, and if it exceeds a certain threshold, to abort the test anyway. We shouldn't continue running a test where each VU panics each iteration...

[mstoykov]

The adding of recover was added in #1697
The rest I think is part of the #877

[na--]

Yeah, if panics don't completely bork the goja runtime and it can run new iterations, we can basically treat them as an exception and an aborted iteration, so #877 should suffice.