Support directly mmap-ing datafiles

[danpat]

Issue

This PR completes the vision initially described in #1947. It builds on the work done by @TheMarex in #4881

Turns out, #4881 was almost there, it really only required the following changes:

• ensuring the bit-vector on-disk layout matched the memory format expected by vector_view<bool>,
• implementing a DataLayout override that understands data block offsets inside tarfiles directly, and
• some special handling for the R-Tree .fileIndex

Fortunately, .tar files are block aligned on 512 byte boundaries - this conveniently means the data is properly word aligned if we directly mmap the entire .tar file.

There is no change here to the pre-processing tooling. However, osrm-routed (and the NodeJS bindings), now support the --mmap (or mmap_memory: true for NodeJS) options. When triggered, instead of loading all data into RAM, this causes OSRM to directly mmap datafiles.

This means you can run OSRM in quite constrained memory environments, if you're willing to sacrifice performance. Supplying sufficient memory to allow page caching to have effect means that if your data has some common access patterns, you can achieve quite good performance with significantly less runtime RAM. Realistic benchmarking for your particular scenario is necessary to decide how much RAM will give you acceptible performance, but at least now this knob exists to tune.

Tasklist

• Rename the ContiguousDataFacade - it no longer depends on the data being contiguous
• Rename DataLayout to ContiguousDataLayout - this is where the contiguous idea is encalsulated
• CHANGELOG.md entry (How to write a changelog entry)
• update relevant Wiki pages
• add tests (see testing documentation
• review
• adjust for comments
• cherry pick to release branch