I believe the actual issue reported in #22 is that, with the old disk region
allocation scheme, we could need one more disk segment list, such that
FCO_REGIONS_RESERVE was too small.

But pondering this issue, I went back to square one and re-thought the
allocation plan. I now think that there were some fundamental flaws in the
previous allocation code:

- we did not plan for how many segment lists we would actually need
- we would cram the segment allocation, which could lead to the number of
  segment lists growing
- for growing allocations, we would switch from "assume we have enough regions"
  to "assume we have no regions at all any more" when FCO_REGIONS_RESERVE was
  reached.

Hopefully, this new allocation plan code now takes a more sensible, holistic
approach:

Whenever we need more disk space (= another disk region), we calculate how many
regions we are sensibly going to need in total. For no cram, this is just one,
and for abs(cram) >=1 it is going to be the number of one-bits (popcount) of the
size. Then we calculate the chunk size which we need to go to in order to fit
all segments into segment lists. Based on this outcome, we calculate a maximum
cam which we can allow for region allocations.

This approach is fundamentally different to before in that we no longer cram
segment sizes - which was wrong, because we do not have an infinite number of
segment lists.

Fixes #22 for real now, I hope