Renamed lfs->cfg->shrub_size -> lfs->cfg->inline_size

While I think shrub_size is probably the more correct name at a
technical level, inline_size is probably more what users expect and
doesn't require a deeper understanding of filesystem details.

The only risk is that users may think inline_size has no effect on large
files, when in fact it still controls how much of the btree root can be
inlined.

There's also the point that sticking with inline_size maintains
compatibility with both the upstream version and any future version that
has other file representations.

May revisit this, but renaming to lfs->cfg->inline_size for now.

tests/test_ck.toml

@@ -1657,7 +1657,7 @@ code = '''
 defines.BADBIT = -1
 defines.BADBLOCK_BEHAVIOR = 'LFS_EMUBD_BADBLOCK_PROGFLIP'
 # force the file to create a btree
-defines.SHRUB_SIZE = 0
+defines.INLINE_SIZE = 0
 defines.CRYSTAL_THRESH = -1
 defines.FRAGMENT_SIZE = 'BLOCK_SIZE/8'
 defines.SIZE = '2*FRAGMENT_SIZE'
@@ -1956,7 +1956,7 @@ code = '''
 [cases.test_ck_ckfetches_btree]
 defines.BADBIT = -1
 # force the file to create a btree
-defines.SHRUB_SIZE = 0
+defines.INLINE_SIZE = 0
 defines.CRYSTAL_THRESH = -1
 defines.FRAGMENT_SIZE = 'BLOCK_SIZE/8'
 defines.SIZE = '2*FRAGMENT_SIZE'
@@ -2213,7 +2213,7 @@ defines.BADBLOCK_BEHAVIOR = [
     'LFS_EMUBD_BADBLOCK_READFLIP',
 ]
 # force the file to create a btree
-defines.SHRUB_SIZE = 0
+defines.INLINE_SIZE = 0
 defines.CRYSTAL_THRESH = -1
 defines.FRAGMENT_SIZE = 'BLOCK_SIZE/8'
 defines.SIZE = '2*FRAGMENT_SIZE'