Adopted more single-char field names

Limited to nested struct fields where the names don't really matter:

- bptr.data -> bptr.d
- mdir.rbyd -> mdir.r

Ok it actually just ended up those two.

This is on the tail end of some optimization work that ended up
abandoned because of maintainability concerns. But it did highlight that
struct nesting gets a bit out-of-control when trying to both optimize
stack allocations and respect C99's strict aliasing.

Consider further fragmenting lfs3_rbyd_t for fine-grain stack
allocations:

  typedef struct lfs3_rbyd {
      struct lfs3_rtrunkcksum {
          struct lfs3_rtrunk {
              lfs3_rid_t weight;
              struct lfs3_rtrunktrunk {
                  lfs3_block_t blocks[2];
                  lfs3_size_t trunk;
              } rtrunktrunk;
          } rtrunk;
          uint32_t cksum;
      } rtrunkcksum;
      lfs3_size_t eoff;
  } lfs3_rbyd_t;

Accessing fields just starts to get silly:

  rbyd.rtrunkcksum.rtrunk.trunktrunk.trunk

At least single-char field names keeps a little bit of readability:

  rbyd.ck.t.t.trunk

Or for some real examples:

- file->b.o.mdir.rbyd.weight -> file->b.o.mdir.r.weight
- bptr->data.u.disk.block -> bptr->d.u.disk.block

lfs3.h

@@ -655,7 +655,7 @@ typedef struct lfs3_bptr {
     // sign2(size)=0b00 => in-RAM buffer
     // sign2(size)=0b10 => on-disk data
     // sign2(size)=0b11 => block pointer
-    lfs3_data_t data;
+    lfs3_data_t d;
     #if !defined(LFS3_2BONLY) && !defined(LFS3_CKDATACKSUMREADS)
     // sign(cksize)=0 => block not erased
     // sign(cksize)=1 => block erased
@@ -687,7 +687,7 @@ typedef lfs3_rbyd_t lfs3_btree_t;
 // littlefs's atomic metadata log type
 typedef struct lfs3_mdir {
     lfs3_smid_t mid;
-    lfs3_rbyd_t rbyd;
+    lfs3_rbyd_t r;
     uint32_t gcksumdelta;
 } lfs3_mdir_t;