Improve time unit granularity for CSV file output from test runs

[rpocklin]

Currently output from test runs can be stored in JSON or CSV file formats.

In JSON, the timestamp of each event sampled is in in ISO8601 format when serialized (eg. {time: "2021-12-01T14:04:26.5295103+11:00"} which has 7 decimal places, but in the CSV output it is defined as Time.Unix() which is only give second level granularity (eg. 1638331259), which is not sufficient when looking at load and performance tests.

I don't see a way to specify the desired format easily across output formats, but recommend at least it have a sufficient level of granularity to compare test runs on an intra-second scale. It may be better to have both file formats output the same format, but currently it is already different.

Here is a PR to improve this (but am open to other suggestions and feedback of course) which uses UnixMicro() to add 6 decimal places of granularity to the timestamp for CSV file output: #2274

[na--]

This was originally supposed to be closed by #2274, though in the end the PR was trimmed down and didn't actually fully resolve this issue. It just laid out the groundwork by adding a timeFormat option and support for RFC3399, but that support was still limited to 1-second precision. #2906 then fully resolved it by adding nanosecond precision and will be released in the upcoming k6 v0.44.0.

[fenchu]

Tested v0.44.1 and I still get sec timestamp resolution: #2839