New JS API for controlling and inspecting VU behavior

[na--]

As I mentioned in #1682 (review), we should try to avoid the addition of complicated global options that control per-VU behavior. They are way too complex and insufficiently flexible at the same time.

Instead, if a particular behavior is local for a VU, there is no reason why we shouldn't have a JS API that can be used to control it. Given that each VU is a single-threaded JS runtime, we might not even need to add any locking in order to implement these VU-controlling APIs. And these API can be built bit by bit - no need to make a new mega project.

Some examples of things that can probably be controlled with such per-VU JS APIs:

• The local IP which a VU is using at the time (the original prompt for writing this issue)
• Modification of various connectivity options - blockHostnames, blacklistIPs, hosts, even things like connection reuse (i.e. changing noVUConnectionReuse / noConnectionReuse, a method to close currently open connections, etc.), etc. We shouldn't allow the global options to be negated, but I don't see a reason why they can't be expanded.
• If we ever implement a per-VU DNS cache (the current one is global, but that can be changed with another --dns sub-option), we should also be able to work with the VU DNS cache from inside of the script - query it, clear it, add to it, etc.
• Various HTTP options that are currently global, like throw, userAgent, discardResponseBodies, TLS settings, rps, batch, batchPerHost, proxies (Allow proxy config per request #1045), HTTP options (Support unencrypted HTTP/2 connections (i.e. h2c) #970, Any way to force to use HTTP/1.1 protocol #936), cookie handing, etc. We want these options to be controllable via the new HTTP API as well, so we'll probably never implement this, but in theory there is nothing stopping us from modifying these global options from inside of the VU. They are currently the global options and you can't change them, but when we have custom HTTP clients, these global options will simply become the default options, so there should be no conflict in allowing them to be changed now or then (just probably no point if we have custom HTTP clients).

A lot of these are not very urgent or even necessary changes, so we may never implement them (unless we're presented with some good use cases, of course). I'm just given them as possible examples, since I think we should strive to limit our future usage of inflexible global options where we can (#883)...

The trackMetric() / untrackMetric() API proposed in #1321 also partially falls under this proposal, though it probably also has global repercussions, especially when it comes to submetrics. Though actions like modifying the currently enabled systemTags and messing with the per-testrun/per-scenario tags values have some merit and can be considered a part of this issue as well...

This also has significant overlap with the proposed API to retrieve execution information (#1320), though that one would also require the querying of state from outside of the current VU.

[na--]

It's probably worth mentioning that part of this was recently implemented and released in k6 v0.35.0 - users can now control what extra tags VUs will attach to emitted metric samples through the k6/execution.vu.tags map.