The old code was written with care to avoid problems
with >2GB indexes on 32-bit machines, using uint32
offsets throughout. But then it mmap'ed the index file,
which wouldn't work with a >2GB index anyway, so none
of that code was really useful in the end.

Move the code to use int for offsets and values throughout.
This will still not work well with >2GB indexes on 32-bit
machines, but again the code already doesn't work in that case.
Now it may at least diagnose the problem a bit better.

The old uint32 code did work well for up to 4GB indexes
on 64-bit machines. This is in preparation for >4GB indexes.

Writing is controlled (for testing) by a global bool.
Reading automatically adapts to the input file.

Writing a new index file makes very little sense.
The only possible benefit would be if there was
memory fragmentation that meant individual 64MB
mmaps would fit but one giant one would not.
That's a rather specific condition that doesn't merit
the complexity. Also, some systems have a low fd limit,
so keeping one file open per segment might run into that
for large indexes.

The old code was writing out the posting lists as raw uint64 slices,
but the entropy on these is quite low. Indexing the Linux 5.4 tree,
the old code wrote 12 segments of 64 MB each = 768 MB.
The new code writes 12 segments of ~9.2 MB each = 110 MB.
The factor of almost exactly 7 is consistent with other trees too,
although I can't explain why 7.

If the index ends up being 10 GB, not writing 70 GB of temp data
is a good thing on systems without tons of free disk space.

Since the 64-bit indexes will be unintelligible to
32-bit csearch anyway, we can take this opportunity
to make other file format adjustments.

Change the encoding of posting lists from byte-level
varint encoding to bit-level γ-encoding. The minimum
number of bits for each fileid delta drops from 8 to 3.
Indexing the Linux 5.4 tree, the 12 sorted segments that
were reduced from 768 MB to 110 MB by varint-encoding
are now reduced further to 77 MB by gamma-encoding.
The index itself is reduced from 119 MB to 87 MB.

The time required to index the tree is up 30%, from
about 14 seconds to about 18 seconds.

The time required for csearch -l '^printf' in the Linux index
is perhaps up 2%, from 0.46 to 0.47 seconds.

A zip file z.zip containing file f is named "z.zip#f" in messages.
A more natural syntax was z.zip:f but the : seemed to get lost
in large lists of file names, especially compared to its importance.
Worse, with "z.zip:f:match" it was unclear whether "z.zip" contained
"f:match" or "z.zip" contained file "f" which contained "match".
"z.zip#f:match" is clearer and evokes HTML URL anchor fragments.

Prefix-compress root and name lists in blocks of 16 paths.
The prefix compression saves 4X, even more with long names.
The blocking preserves random access to the name list and
also reduces the name index size by 16X.

Improve γ-coding of posting lists by inserting 0 at 16 instead
of inserting it at 1. Since 1 is the most common coded value,
it should keep the 1-bit representation. Empirically, mapping 0
into the 4-bit values is the best choice for space savings.

Varint-encode the posting list index entries, saving 2-3X.
This matters most for small indexes; in large indexes the
posting lists themselves dominate the posting list index.

Also start on HTML output for a possible web interface.

cmd/cgrep: add -v flag

Experimental and not very useful yet.