Replaced inlined lfsr_data_t with a lazily encoded leb128

The idea is that we can save on the cost of calling lfs_toleb128
everywhere we commit leb128s, by lazily encoding during progdata.

I original thought this would have too many small problems, but:

1. We can actually implement slice surprisingly easily by just shifting
   the internal word 7 bits. This emulates byte-level slicing in the
   encoded leb128.

   This enables read/cmp, so we can implement all of the lfsr_data_t
   functions, though it does make lfs_toleb128 required for a readonly
   implementation, which isn't great. Sufficient creativity with ifdefs
   likely makes this a non-problem though.

2. There's really very limited use cases for non-leb128 inlined datas.

   We can use it to encode the version and compatflags during
   lfs_format, but that's about it. And lfs_format is definitely not on
   the stack hot-path, so there's no reason to not use on-stack buffers
   for these.

The original motivation for this change was noticing a surprising amount
of code savings related to lazy leb128 encoding in another lfsr_data_t
refactor. Unfortunately this savings does not seem reproducible:

           code          stack
  before: 33864           2880
  after:  33912 (+0.1%)   2888 (+0.3%)

But that's ok, this is closer to what I expected. The lfs_sizeleb128
call we need to predict the leb128 size is close to the same cost as
calling lfs_toleb128 so the savings isn't really that much.

lfs_util.h

@@ -348,6 +348,11 @@ ssize_t lfs_toleb128(uint32_t word, void *buffer, size_t size);
 
 ssize_t lfs_fromleb128(uint32_t *word, const void *buffer, size_t size);
 
+// Calculate the on-disk size of a leb128 without actually encoding
+static inline size_t lfs_sizeleb128(uint32_t word) {
+    return (lfs_nlog2(word+1)+7-1) / 7;
+}
+
 
 
 // Calculate CRC-32 with polynomial = 0x04c11db7