Reverted limiting file->leaf to reads + erased-state caching

Still on the fence about this, but in hindsight the code/stack
difference is not _that_ much:

           code          stack          ctx
  before: 36460           2280          636
  after:  37092 (+1.7%)   2304 (+1.1%)  636 (+0.0%)

Especially with the potential to significantly speed up linear file
writes/rewrites, which are usually the most common file operation. You
ever just, you know, write a whole file at once?

Note we can still add the previous behavior as an opt-in write strategy
to save code/stack when preferred over linear write/rewrite speed.

This is actually the main reason I think we should prefer
lazy-crystallization by default. Of the theoretical/future write
strategies, lazy-crystallization was the only one trading performance
for code/stack and not vice versa (global-alignment, linear-only,
fully-fragmented, etc).

If we default to a small, but less performant filesystem, it risks users
thinking littlefs is slow when they just haven't turned on the right
flags.

That being said there's a balance here. Users will probably judge
littlefs based on its default code size for the same reason.

---

Note this includes the generalized lfsr_file_crystallize_ API, which
adds a bit of code:

                     code          stack          ctx
  before gen-cryst: 37084           2304          636
  after gen-cryst:  37092 (+0.0%)   2304 (+0.0%)  636 (+0.0%)

lfs.h

@@ -144,6 +144,8 @@ enum lfs_type {
 
 // internally used flags, don't use these
 #define LFS_o_TYPE      0xf0000000  // The file's type
+#define LFS_o_UNCRYST   0x00400000  // File's leaf not fully crystallized
+#define LFS_o_UNGRAFT   0x00800000  // File's leaf does not match bshrub/btree
 #define LFS_o_UNFLUSH   0x01000000  // File's data does not match disk
 #define LFS_o_UNSYNC    0x02000000  // File's metadata does not match disk
 #define LFS_o_UNCREAT   0x04000000  // File does not exist yet