Don't propagate grm cleanup errors

While it may be useful to know when/why lfsr_fs_fixgrm fails, at this
point in lfsr_rename/lfsr_remove the operation has already succeeded as
far as the filesystem is concerned.

It's counterintuitive, but ignoring these errors actually tells the user
_more_ information, specifically whether or not the operation completed
on disk.

At least we can log the error via LFS_WARN, and such errors will likely
come up again in a future operation, such as the call to lfsr_fs_fixgrm
on the next filesystem mutation.

This was noticed in test_grow, which tests error code-paths quite a bit
more than any other test.

Code changes:

           code          stack
  before: 33934           2592
  after:  33942 (+0.0%)   2592 (+0.0%)

lfs.c

@@ -9536,7 +9536,14 @@ int lfsr_remove(lfs_t *lfs, const char *path) {
 
     // if we were a directory, we need to clean up, fortunately we can leave
     // this up to lfsr_fs_fixgrm
-    return lfsr_fs_fixgrm(lfs);
+    err = lfsr_fs_fixgrm(lfs);
+    if (err) {
+        // we did complete the remove, so we shouldn't error here, best
+        // we can do is log this
+        LFS_WARN("Failed to clean up grm (%d)", err);
+    }
+
+    return 0;
 }
 
 int lfsr_rename(lfs_t *lfs, const char *old_path, const char *new_path) {
@@ -9705,7 +9712,14 @@ int lfsr_rename(lfs_t *lfs, const char *old_path, const char *new_path) {
 
     // we need to clean up any pending grms, fortunately we can leave
     // this up to lfsr_fs_fixgrm
-    return lfsr_fs_fixgrm(lfs);
+    err = lfsr_fs_fixgrm(lfs);
+    if (err) {
+        // we did complete the remove, so we shouldn't error here, best
+        // we can do is log this
+        LFS_WARN("Failed to clean up grm (%d)", err);
+    }
+
+    return 0;
 }
 
 // this just populates the info struct based on what we found