Dropped lfsr_dir_t's bookmark mdir, switched to did for dir updates

This simplification comes from the observation that we don't actually
need to know the bookmark's mid to know if a given operation is in a
dir's range, just the dir's did. And since dids are immutable, we don't
need another opened-list entry or other shenanigans.

A dir's did is a bit harder to access, requiring a name lookup, but we
conveniently already fetch these in all relevant functions as a part of
path resolution.

This does mean more opened-list logic in the high-level functions:

  function              can zombie  can create  can remove
  lfsr_mkdir                     y           y           n
  lfsr_rename                    y           y           y
  lfsr_remove                    y           n           y
  lfsr_file_opencfg              y           y           n

But I think this actually results in better code readability, since the
opened-list logic and high-level logic are closely related. I went ahead
and lifted the similar orphan/zombie opened-list logic up to this level
for this reason.

Unfortunately lifting this logic does result in a higher code cost, but
I think this is worth it for better readability and a significantly
reduced RAM cost for lfsr_dir_ts. Keep in mind these will probably
become very common for the future planned openat/*at functions:

           code          stack          lfsr_dir_t
  before: 33402           2632                  80
  after:  33582 (+0.5%)   2632 (+0.0%)          44 (-45.0%)

Also added a new test case, test_dread_read_rm_remkdir, to catch the
mistake of thinking the did is unique even when the dir is removed,
since that is now a concern.

lfs.h

@@ -453,8 +453,7 @@ typedef struct lfsr_data {
 //} lfs_dir_t;
 
 typedef struct lfsr_dir {
-    lfsr_opened_t p; // pos mdir
-    lfsr_opened_t b; // bookmark mdir
+    lfsr_opened_t m;
     lfsr_did_t did;
     lfs_off_t pos;
 } lfsr_dir_t;