Attempted to merge the mid's bid and rid into a single integer

This didn't really work out as well as I had hoped. There were a few
ideas on how to encode the bid/rid tuple without sacrificing the
(currently 31-bit) integer limit, but these just introduced too much
complexity.

Ideas:

1. In theory, as the mdirs increase in size, the quantity of mdirs needed
   for a given number of files decreases. If we say the number of files
   fits in an integer of a given size, than we can model the mapping to
   mdirs and rids roughly as the number of bits in that integer split
   between the two.

   Since the block_size is known, the we can find a rather conservative,
   yet useful, estimate of the upper bound of rids, which ends up
   being ~16 bytes ((2 alts + 1 null + 1 tag) * 4 bytes).

   And since our btrees are perfectly balanced, this encoding should only
   waste 1 or 2 bits due to rounding to rounding and sign encoding for
   special values.

     bbbbbbbb bbbbbbbb bbbbbbbr rrrrrrrr
     '-----------+-----------''----+---'
                 |                 '-- log2(block_size/32)-bit rid
                 '-------------------- remaining-bit bid

   Unfortunately, while this works ok on paper, and maximize the use of
   the bits we have available for the mid, the implementation ended up
   awkward and difficult to use.

   We need to either calculate the relatively complciated log2 of the
   block_size on the fly, or cache the value, and use it to shift the
   mid around to extract the bid/rid when needed.

   Unfortunately, perhaps due to the it being easy to use the bid/rid
   directly, we use and mutate the bid/rid quite a bit. We mutate when
   updating the mdirs, when decoding grms, when seeking mdirs, etc. If
   anything, updating the mid in total is rarer than updating the
   bid/rid component in complicated situations.

   Note to mention this required access to the lfs config to even begin
   decoding, complicating the API and making the result less efficient.

   Initial (unoptimized, and not even tested) code size showed ~+800
   bytes. So I decided to scrap this.

   Maybe it will be worth investigating dynamic rid sizes later, to
   increase the possible mtree size for a given mid width. Not sure.

2. Probably one of the worst ideas I've had so far, but it would solve
   the mid encoding problem, is to use some form a floating point to
   encode the bid/rid pair:

                          .----------.
                          v         .+-.
     bbbbbbbb bbbbbbbb bbbrrrrr rrrrssss
     '-----------+-------''----+---''-+'
                 |             |      '-- rid bits
                 |             '--------- variable rid
                 '----------------------- variable bid

    An even worse idea would be to use IEEE floating point here. Yes it
    would work, and probably work annoyingly well, but we it risk
    bringing in a lot of standard conforming backbending that we really
    don't care about.

    The idea here is to sacrifice some bits to encode the ratio of rid
    bits to bid bits. The value of this over the using the block_size is
    that we can decode the bid and rid using all of the bits in the
    integer alone. Avoiding memory access (and worse debugging) to load
    any external constants.

    As a plus, all mids in the system would have the same exponent,
    simplifying comparisons and other operations.

    But this is just trying to solve complexity by adding more
    complexity, so I'm not even going to try implementing it.

    Still, it's an interesting idea...

In the end I've gone with the KISS implementation. Use half-width
integers, in this case uint16s, for both the bid and rid:

  bbbbbbbb bbbbbbbb rrrrrrrr rrrrrrrr
  '-------+-------' '-------+-------'
          |                 '-- 16-bit rid
          '-------------------- 16-bit bid

This suffers from weakened limits around the number of rids in a block
and number of mdirs in the mtree, which is unfortunate. Still it is
probably worth the tradeoff for the RAM savings and encoding simplicity.

If the mdir is reasonably sized, this does probably approach a decent
distribution of rids and bids in 32-bits. But for outlier cases with
very small and very large mdirs, it risks premature out of bounds
errors.

To protect against mtree errors, we will probably need an additional
configuration option in the form of an mdir limit. Conveniently this
would also provide a way to enforce 2-block mode.

rid errors, on the other hand, depend on block_size/32, so we may not
need another configuration option and can rely on the block_size
to determine if the rids can overflow.

This is probably worth revisiting in the future. Fortunately, with
mdir_limit and block_size configuration options, it should be possible
to increase these limits in the future if this mid bid/rid design
changes.

            code          stack
  before:  22126           2136
  after:   22326 (+0.9%)   2088 (-2.2%)

This code size increase was unexpected. Maybe non-32-bit-aligned integers
cost more to load in thumb? Unsure.

tests/t4_alloc.toml

@@ -108,8 +108,9 @@ code = '''
             LFSR_ATTR(0, UNR, -1, NULL, 0))) => 0;
 
     lfsr_mdir_t mdir;
-    lfsr_mtree_lookup(&lfs, lfsr_mtree_weight(&lfs)-1, -1, &mdir) => 0;
-    mdir.rid = 0;
+    lfsr_mtree_lookup(&lfs, LFSR_MID(lfsr_mtree_weight(&lfs)-1, -1),
+            &mdir) => 0;
+    mdir.mid.rid = 0;
 
     lfs_size_t count = 0;
     while (true) {
@@ -121,19 +122,19 @@ code = '''
 
         // keep creating new metadata entries until we run out of space
         int err = lfsr_mdir_commit(&lfs, &mdir, LFSR_ATTRS(
-                LFSR_ATTR(mdir.rid, INLINED, +1, &alphas[count % 26], 1)));
+                LFSR_ATTR(mdir.mid.rid, INLINED, +1, &alphas[count % 26], 1)));
         assert(!err || err == LFS_ERR_NOSPC);
         if (err == LFS_ERR_NOSPC) {
             break;
         }
 
         uint8_t buffer[4];
-        lfsr_mdir_get(&lfs, &mdir, mdir.rid, LFSR_TAG_INLINED,
+        lfsr_mdir_get(&lfs, &mdir, mdir.mid.rid, LFSR_TAG_INLINED,
                 buffer, 4) => 1;
         assert(memcmp(buffer, &alphas[count % 26], 1) == 0);
 
         count += 1;
-        mdir.rid += 1;
+        mdir.mid.rid += 1;
     }
 
     printf("alloced %d metadata entries in %d blocks\n",
@@ -145,12 +146,12 @@ code = '''
             mid < (lfs_ssize_t)lfsr_mtree_weight(&lfs);
             mid++) {
         lfsr_mdir_t mdir;
-        lfsr_mtree_lookup(&lfs, mid, -1, &mdir) => 0;
-        for (mdir.rid = 0;
-                mdir.rid < (lfs_ssize_t)mdir.m.rbyd.weight;
-                mdir.rid++) {
+        lfsr_mtree_lookup(&lfs, LFSR_MID(mid, -1), &mdir) => 0;
+        for (mdir.mid.rid = 0;
+                mdir.mid.rid < (lfs_ssize_t)mdir.m.rbyd.weight;
+                mdir.mid.rid++) {
             uint8_t buffer[4];
-            lfsr_mdir_get(&lfs, &mdir, mdir.rid, LFSR_TAG_INLINED,
+            lfsr_mdir_get(&lfs, &mdir, mdir.mid.rid, LFSR_TAG_INLINED,
                     buffer, 4) => 1;
             assert(memcmp(buffer, &alphas[i % 26], 1) == 0);
             i += 1;