Introduced cache_size as alternative to hardware read/write sizes

The introduction of an explicit cache_size configuration allows
customization of the cache buffers independently from the hardware
read/write sizes.

This has been one of littlefs's main handicaps. Without a distinction
between cache units and hardware limitations, littlefs isn't able to
read or program _less_ than the cache size. This leads to the
counter-intuitive case where larger cache sizes can actually be harmful,
since larger read/prog sizes require sending more data over the bus if
we're only accessing a small set of data (for example the CTZ skip-list
traversal).

This is compounded with metadata logging, since a large program size
limits the number of commits we can write out in a single metadata
block. It really doesn't make sense to link program size + cache
size here.

With a separate cache_size configuration, we can be much smarter about
what we actually read/write from disk.

This also simplifies cache handling a bit. Before there were two
possible cache sizes, but these were rarely used. Note that the
cache_size is NOT written to the superblock and can be freely changed
without breaking backwards compatibility.

tests/template.fmt

@@ -66,7 +66,11 @@ uintmax_t test;
 #endif
 
 #ifndef LFS_PROG_SIZE
-#define LFS_PROG_SIZE 16
+#define LFS_PROG_SIZE LFS_READ_SIZE
+#endif
+
+#ifndef LFS_CACHE_SIZE
+#define LFS_CACHE_SIZE 64
 #endif
 
 #ifndef LFS_BLOCK_SIZE
@@ -92,6 +96,7 @@ const struct lfs_config cfg = {{
 
     .read_size   = LFS_READ_SIZE,
     .prog_size   = LFS_PROG_SIZE,
+    .cache_size  = LFS_CACHE_SIZE,
     .block_size  = LFS_BLOCK_SIZE,
     .block_count = LFS_BLOCK_COUNT,
     .lookahead   = LFS_LOOKAHEAD,