check-in v1: richer input for urlgetter: discuss prototype

[bassosimone]

Similar to #754, but for urlgetter. The main task here is not necessarily implementing and merging, rather discussing a prototype implementation and decide whether it would make sense to merge or whether it could tie our hands for the future. More specifically, consider the following:

1. if we define richer input like we plan on doing for dnscheck (see also the plan at Write a design document for how to support richer testing input ooni.org#1295), we can support a wide array of urlgetter based experiments;

2. however, doing that could be binding because we never defined what urlgetter options are supported in the long run;

I would like to discuss with @ooni/ooni-team which options we want to support and whether there is a way for us to be even more flexible with respect to richer input as far as the urlgetter experiment is concerned.

[bassosimone]

As discussed in ooni/probe-cli#1621 and considering previous conversations with Arturo and given the work he's been doing to divide the backend in tiers, it's not critical anymore to discuss a prototype and we can just follow the new pattern of having a microservice for serving this kind of richer input (or a pool of related inputs that are all deemed not P0) without the need to have extensive discussions. Yay for the tier architecture!