Tweaked cache size to temporarily avoid pathological shrub overflows

This will stop being a problem when we actually have btrees, but for now
the fragmentation caused by byte-level syncs was easily enough to
overflow an mdir when cache size is big.

A smaller cache size is also nicer for debugging, since smaller cache
sizes results in data getting flushed to disk earlier, which is easier
to inspect than in-device buffers. And a 16-byte cache still provides
decent test coverage over cache interactions.

---

Also dropped inline_size to block_size/8. I realized while debugging
that opened shrubs take up additional space until we sync, so we need to
expect up to 2 temporary copies of shrubs when writing files.

tests/test_ftree.toml

@@ -510,6 +510,7 @@ code = '''
 # write files incrementally
 [cases.test_ftree_incr]
 defines.SIZE = ['CACHE_SIZE/2', '2*CACHE_SIZE']
+defines.CHUNK = [4, 1]
 defines.SYNC = [false, true]
 defines.REMOUNT = [false, true]
 reentrant = true
@@ -530,7 +531,9 @@ code = '''
     uint32_t prng = 42;
     for (lfs_size_t i = 0; i < SIZE; i++) {
         wbuf[i] = 'a' + (TEST_PRNG(&prng) % 26);
-        lfsr_file_write(&lfs, &file, &wbuf[i], 1) => 1;
+    }
+    for (lfs_size_t i = 0; i < SIZE; i += CHUNK) {
+        lfsr_file_write(&lfs, &file, &wbuf[i], CHUNK) => CHUNK;
 
         // sync?
         if (SYNC) {