engine: introduce executor for richer input

[bassosimone]

In https://github.com/ooni/ooni.org/issues/1295, I suggested to take the following JSON as the smallest executable unit:

{
  "input": "https://dns.google/dns-query",
  "options": {"HTTP3Enabled": true},
  "test_name": "dnscheck"
}

This issue is about writing (well, most likely, refactoring) code to make it possible. A good (but minor) question to ask is whether the structure should be as indicated above, or whether we should instead use:

{
  "inputs": ["https://dns.google/dns-query"],
  "options": {"HTTP3Enabled": true},
  "test_name": "dnscheck"
}

The latter would probably map more cleanly with how we actually execute experiments. However, it would probably be more tidy from the logical model point of view to have an executor that takes in input a list of the former structure rather than one that takes in input a single instance of the latter structure. As a minor, but useful improvement, using the former structure would allow us to get rid of the annoying issue (originating from Measurement Kit) that to execute an input less test you need to supply it as input []string{""}, otherwise it would not run.

[bassosimone]

We introduced the executor, even though we didn't name it explicitly. See https://github.com/ooni/probe-cli/pull/1621 for details. Compare to what we originally thought, here's what ended up being different:

1. Rather than having a global executor, each experiment package implements its own executor using support libraries that we refactored for this purpose. This design is more flexible because we reduce the pressure on the common framework.
2. An ExperimentMeasurer that is richer input aware executes the smallest possible unit, but the framework around it is still executing on the OONI-Run-v2-like data structure because that is more convenient as it fits better with how the code is currently written.
3. The way in which we implemented the changes is that the common framework is ready and we have dnscheck to show us that it is possible to have richer-input experiments. We'll gradually migrate also other experiments.

The latter design choice, in particular, reduced friction for integrating with miniooni and ooniprobe a lot.