feat: Request chaining & Dependency graphs

We'll have to prepare for test cases where we need to have requests and checks that depend on the result of other requests.

For example:
A test wants to query an endpoint, retrieve the ETAG from the response, then check that subsequent calls to the same endpoint reusing the ETAG value gives a _304 - Not Modified_.

We used a minimal approach to implement these test:

```
- define empty variable "etag"
- call Run(test1), which has a Function Check which updates "etag" with a side effect
- call Run(test2, test3) which reuses "etag".
```

@galargh investigated a few approaches:

- define a ["Future"](https://en.wikipedia.org/wiki/Futures_and_promises) that requests might fulfill or use ([PR](https://github.com/ipfs/gateway-conformance/pull/30)).
- have an API to define side-effects ([PR](https://github.com/ipfs/gateway-conformance/pull/96)).

We used a minimal approach instead ([PR](https://github.com/ipfs/gateway-conformance/pull/97)), which does the side-effect explicitly, without endorsing it in the API.

That won't scale to more complex test cases, and we should be ready to implement a "better" approach, ideally, that should:
- make dependencies explicit
- be declarative
- be compatible with the rest of the API (templates, decorators used to generate more tests)
- play nice with IDEs and tooling (use variable instead of raw strings, etc).

Using futures values should work: a future might "taint" values and templates where they are used (templating with a future returns a future). At evaluation time, we can do a topological sort to find the order of execution.

Refs:

- https://marc-ed-raffalli.github.io/declarative-e2e-test/#steps