Making the `k6/experimental/tracing` module part of the k6 core

[oleiade]

Feature Description

A few releases back, we introduced the k6/experimental/tracing module to k6.

Experimental modules intend to become part of the core eventually. Although the module has been around for a while, we have yet to take the opportunity to take a step back and consider what is left to do to reach a state acceptable to become a core module.

We are not aware of issues that would keep us from stabilizing this module at the moment, and unless some are raised, we will stabilize it sooner than later.

### Tasks
- [ ] The team needs to reach an agreement on whether we want to stabilize this module

[mstoykov]

I have done a reimplementation in js here

Notes:

1. if it is hitting a none existing localhost endpoint it seems to be around 80% slower
2. the moment I started hitting something real not on localhost - this dissapered (also obviously the RPS plummetted)
3. this lets you call instrumentHTTP and Client in not init context - while the go one doesn't. I find this to be a bug in the original version
4. we don't really have a way to get nanosecond time in js - so I get millisecond time and multiply it by 1e6. Not certain how relevant that is. This also might slightly mess up the time as it goes in the theritory of float not being accurate. See https://github.com/grafana/k6/issues/2362
5. while I have tested it somewhat locally - someone should definitely try it more with real traffic.
6. edit: this also doesn't cap the provided arguments to 2 (body and params) but also pushes over any additional ones. While this is not really useful it won't break any potential detection that someone is misusing them by providing more arguments.

With this we can allow users to effectively do

import { instrumentHTTP, Client } from "/path/to/tracing-instrumentation.js";
 // including from jslib or directly from the gist or locally

// same as before

edit: I have now fixed instrumentHTTP and some other small issues.