Port backend/legacyapi components over to the ooniapi services pattern

The components that need to be ported are the following:

Tier0

• ooniprobe, (aka probe_services), where probes send their measurements and
  get metadata to run experiments;
  • Measurement collection
  • Fastpath
• prioritization, CRUD for editing the priorities of URLs and populating the
  appropriate clickhouse tables so they can be used by probe: https://github.com/ooni/backend/issues/1007
• test helpers, such as the web connectivity test helper: https://github.com/ooni/backend/issues/1006

Tier1

• data, (aka OONI Data Kraken), where Explorer and other clients access the
  observations data and experiment results;
• findings, (aka incidents) backend for findings pages on explorer (see: https://github.com/ooni/backend/issues/814);
• measurements, backend for aggregation and list measurement endpoints (note
  also probe uses this, so it's maybe on the high end of tier1);

Tier2

• testlists, for proposing changes to the test-lists and submitting a github PR: https://github.com/ooni/backend/issues/1005

For best practices in doing so, see: https://github.com/ooni/backend/issues/817

I started in this PR to define a nice pattern for using fastapi in conjunction with PostgreSQL for the new OONI Run v2 API: https://github.com/ooni/backend/pull/805.

And also:

• https://github.com/ooni/backend/pull/799
• https://github.com/ooni/backend/pull/800
• https://github.com/ooni/backend/pull/801

I think we should adopt this for iteratively refactoring and deploying other OONI backend tier1 components.

For example the censorship findings pages should be moved over to postgresql and refactored to use fastapi.

This is also related to the API gateway work such that we are able to expose these refactored endpoints side by side the old ones minimizing the chance of breakage: https://github.com/ooni/devops/issues/7.