Limit crystal_thresh to >=prog_size

I confused myself a bit while benchmarking because crystal_thresh <
prog_size was showing some very confusing results. But it turns out the
relevant code was just not written well enough to support this
configuration.

And, to be fair, this configuration really doesn't make sense. The whole
point of the fragment + crystallization system is so we never have to
write unaligned data to blocks. I mean, we could explicitly write
padding in this case, but why?

---

This should probably eventually be either an assert or mutable limit,
but in the meantime I'm just adjusting crystal_thresh at runtime, which
adds a bit of code:

           code          stack          ctx
  before: 37076           2352          684
  after:  37112 (+0.1%)   2352 (+0.0%)  684 (+0.0%)

On the plus side, this prevents crystal_thresh=0 issues much more
elegantly.

lfs3.h

@@ -573,9 +573,9 @@ struct lfs3_cfg {
     // values will crystallize more eagerly, reducing disk usage, but
     // increasing the cost of random-writes.
     //
-    // 0 or 1 only writes blocks, minimizing disk usage, while -1 or any
-    // value > block_size only writes fragments, minimizing random-write
-    // cost.
+    // 0 tries to only writes blocks, minimizing disk usage, while -1 or
+    // any value > block_size only writes fragments, minimizing
+    // random-write cost.
     #ifndef LFS3_RDONLY
     lfs3_size_t crystal_thresh;
     #endif