Port backend/legacyapi components over to the ooniapi services pattern

[hellais]

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;
• prioritization, CRUD for editing the priorities of URLs and populating the
  appropriate clickhouse tables so they can be used by probe;
• test helpers, such as the web connectivity test helper

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: Port findings platform over to new pattern #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;

For best practices in doing so, see: #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: #805.

And also:

• 2024-refactor part 1/3 Move aggregation and measurement into refactoring dir #799
• 2024 refactor part 2/3: fastapi refactor #800
• 2024 refactor part 3/3: cleanup #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: ooni/devops#7.