minitrace-tests: async_std runtime as default

[taqtiqa-mark]

This arose in the course of #113 and PR #127.

Currently, the proc-macro code is the, largely, tokio specific code, per this comment.

In fact, at the time of writing, all tests are carried out using the Tokio runtime.

Ideally, IMO, we'd like to support embedded device developers (issue #131). To do so requires adding another runtime to the test infrastructure.
An incremental step in the test infrastructure in that direction is to add another (non-embedded) runtime.
The only other real alternative to Tokio is async-std.

A less painful route to add async-std to the test suite is to ensure we can always isolate all tokio tests, and ensure they remain green - while other runtime tests evolve in the background without breaking CI.
This means gathering/isolating existing tests under something like crfg_attr/cfg(features = "minitrace-tests/tk")

Ironically, this biases toward some other runtime "naturally" become the default, i.e. when there is no feature guard. Which suggests async-std would, eventually, in the fullness of time, etc., be the default test environment.

I'm not unhappy with this serendipitous outcome, since async-std is explicitly aiming at Rust std lib feel, see here.

That said, there maybe a performance cost to async-std over tokio that others weigh more heavily.

However, we are only talking about the minitrace-tests crate, so there is nothing user impacting in this decision....

Thoughts?

[taqtiqa-mark]

The integration test harness that appears to be the most inituitive and ergonomic doesn't permit a default runtime using features - without incurring some unexpected behavior, like being triggered by cargo test -- --list.

Closing until proved otherwise.