Use the debugger rendez-vous to populate the module list on Linux - #195

The branch is based on top of #194 to make my life easier debugging Android issues, hence the Draft status, although I'm not sure if the CI runs on draft PRs?

I think I'm getting there in terms of understanding this code, and I think we
might need to change the approach a bit.

AFAICT, the reason we want to use the rendezvous data is to generate a more
accurate ModulesList stream. What that means exactly remains to be determined:

• Do we want the exact executable code mapping, single-byte precision, or are
  we aiming for a broader data set that includes alignment-induced padding? The
  current procmaps code seems to be in the latter case, judging by the aggregate()
  algorithm.

• do we want to include .bss sections and similar, or limit ourselves to
  executable stuff? In the current code, pretty much anything that's explicitly
  file-backed (which excludes .bss and similar sections) and contiguous to a
  code+padding section gets thrown in.

Another question: do we really want this as a fallback? Instead, I'd rather
have this data as primary source, but used only to populate the ModulesList.
As it stands, the data structure that is populated in the current implementation
is also used for other purposes, where that data source is a pretty poor fit:

• Thread stacktraces. In order to walk the stacks, we must first identify the stack
  mappings. The new data source doesn't know about those since it's not ELF-derivated.
• IP lookups. On its face it seems reasonable to expect the instruction pointer to
  point within an ELF codepage, but then you remember about JIT-generated code...

My proposed new implementation plan is thus the following:

• Keep the current procmap-based data source for general mapping data
• Use the rendezvous data source to populate a separate module data structure,
  with a fallback to the previous procmaps approach
• Add a config knob to force the use of the fallback, to make it easy for us
  to have a progressive rollout (credits to @marti4d for that idea)

Assuming you'll agree with that plan, I'll still need clarification on which
data we want in the modules list to finalize the work, but I can already get
started on the overall architecture.