Revisited caching rules to optimize bus transactions

The littlefs driver has always had this really weird quirk: larger cache
sizes can significantly harm performance. This has probably been one of
the most surprising pieces of configuraing and optimizing littlefs.

The reason is that littlefs's caches are kinda dumb (this is somewhat
intentional, as dumb caches take up much less code space than smart
caches). When littlefs needs to read data, it will load the entire cache
line. This means that even when we only need a small 4 byte piece of
data, we may need to read a full 512 byte cache. And since
microcontrollers may be reading from storage over relatively slow bus
protocols, the time to send data over the bus may dominate other
operations.

Now that we have separate configuration options for "cache_size" and
"read_size", we can start making littlefs's caches a bit smarter. They
aren't going to be perfect, because code size is still a priority, but
there are some small improvements we can do:

1. Program caches write to prog_size aligned units, but eagerly cache as
   much as possible. There's no downside to using the full cache in
   program operations.

2. Add a hint parameter to cached reads. This internal API allows callers
   to tell the cache how much data they expect to need. This avoids
   excess bus traffic, and now we can even bypass the cache if the
   caller provides enough of a buffer.

   We can still fall back to reading full cache-lines in the cases where
   we don't know how much data we need by providing the block size as
   the hint. We do this for directory fetches and for file reads.

This has immediate improvements for both metadata-log traversal and CTZ
skip-list traversal, since these both only need to read 4-byte pointers
and can always bypass the cache, allowing reuse elsewhere.