Rerouted all btree mutation through attr-list parser

The idea here: Instead of having unique functionality for each
individual btree operation (push/set/pop/split), we treat btrees sort of
like rbyds, with a single commit entry point that operates on attr-lists.

This adds code cost, due to needing to parse the attr-list for properties
that can affect inlined btrees (tag changes mostly), but, in theory, comes
with some advantages:

1. A single btree commit entry point with all of the inlined/uninlining
   logic should offer better chances for code deduplication, vs
   spreading this logic out in each btree operation.

2. Higher-levels should know what the current weight of the branch is,
   so we may be able to avoid the implicit math needed to calculate
   deltas.

3. Higher-levels have more knowledge about the state of the btree in
   general, so there may be other shortcuts. The mtree, for example,
   only operates on weight=1 entries, which greatly simplifies a lot of
   the related math.

Note that btrees still have strict limits in what's possible in an
attr-list. Btree operations can't cross leaf-rbyd boundaries for
example.

---

A notable omission in this change is the loss of reinlining btrees.

This wase dropped for a couple reasons. It may be worth adding back at a
later time, maybe after we actually have files implemented, but for now
does not seem worth it:

1. Reinlining adds code cost. Reinlining is more complex than you might
   expect because we only reinline on compaction. And because we compact
   before playing out our attr-list, we need to know if a commit makes
   the btree inlinable before committing to the btree.

   This is still doable with our attr-lists. We already derive the
   change in tags, since we need this to know when to uninline. But it
   adds a kind of complex bailing out of btree commits.

2. The benefits of reinlining may not be that great. In most systems, a
   tree that is uninlined once is likely to be uninlined again. It's
   only if there is a bigger state change in a system that it makes
   sense to reinline.

   Though, to be fair, waiting for compaction to reinline handled this
   quite well. Only reinlining when all erased storage is used up...

3. Thanks to our roots did entry, our mtree can never reinline.

   It would be nice to change this, but this would require explicit
   handling in lfsr_mdir_commit. Future work?

4. Files are another can of worms, with more complex interactions with
   inlinability thanks to (at least on paper right now) always having
   inlined data even when uninlined.

   If reinlining is valuable for files this can change during that work.

5. Even if files never support reinlinability, truncating files (via
   either lfsr_file_truncate or LFSR_O_TRUNC) should give the file a
   blank slate, effectively reinlining the file in that case.

---

The current implementation also changes the attr-list to be mutable so
we can adjust attr-list based on the current btree node. This is a
temporary hack! We should add the appropriate functionality to our rbyd
utilities to revert this eventually.

lfs_util.h

@@ -163,6 +163,7 @@ static inline int32_t lfs_smin32(int32_t a, int32_t b) {
     return (a < b) ? a : b;
 }
 
+// TODO other 16-bit ops?
 static inline uint16_t lfs_max16(uint16_t a, uint16_t b) {
     return (a > b) ? a : b;
 }
@@ -171,6 +172,15 @@ static inline uint16_t lfs_min16(uint16_t a, uint16_t b) {
     return (a < b) ? a : b;
 }
 
+// Clamp is useful as the logic for min/max when clamping can become confusing
+static inline uint32_t lfs_clamp32(uint32_t a, uint32_t min, uint32_t max) {
+    return lfs_min32(lfs_max32(a, min), max);
+}
+
+static inline int32_t lfs_sclamp32(int32_t a, int32_t min, int32_t max) {
+    return lfs_smin32(lfs_smax32(a, min), max);
+}
+
 // Absolute value of signed numbers
 static inline int32_t lfs_abs32(int32_t a) {
     return a < 0 ? -a : a;