Reverted pushed ftree tracking down into lfsr_ftree_carve

None of the available options sit well with me.

Worst case writes states after an error:

1. Maintain on-stack snapshots for entire write operation:

     on-disk: abcdefghijklmnopqrstuvwxyz
     write:            JKLMN
     error!
     on-disk: abcdefghiJKlmnopqrstuvwxyz

2. Maintain on-stack snapshots for lfsr_ftree_carve:

     on-disk: abcdefghijklmnopqrstuvwxyz
     write:            JKLMN
     error!
     on-disk: abcdefghijklmnopqrstuvwxyz

3. Don't maintain on-stack snapshots, rely on btree/bshrub atomicity:

     on-disk: abcdefghijklmnopqrstuvwxyz
     write:            JKLMN
     error!
     on-disk: abcdstuvwxyz

Something else to consider, the on-stack snapshots increase pressure on
the available shrub_size, which must include all tracked bshrubs in the
mdir, and currently doesn't deduplicate more than checking for identical
trunks. In effect, shrubs are limited to ~shrub_size/3, which isn't
great...

Since we can't get rid of the extra shrub cost when atomic carve
operations, I'm going to revert this, since we might as well just track
all file operations and provide a fully atomic API... Element of least
surprise and all thath...

But this revert may itself be reverted in the future.

Maybe we should provide some sort of LFS_LESSATOMIC flag to allow opt-in
to non-atomic file writes for code/stack savings?

lfs.h

@@ -831,10 +831,6 @@ lfs_ssize_t lfsr_file_read(lfs_t *lfs, lfsr_file_t *file,
 // Takes a buffer and size indicating the data to write. The file will not
 // actually be updated on the storage until either sync or close is called.
 //
-// If an error occurs during a write (including LFS_ERR_NOSPC), the file
-// will be marked as desynchronized, the position will be left unchanged,
-// and some, all, or none of the data may be written.
-//
 // Returns the number of bytes written, or a negative error code on failure.
 lfs_ssize_t lfs_file_write(lfs_t *lfs, lfs_file_t *file,
         const void *buffer, lfs_size_t size);