Fix (unreported) broken collections after undo/redo, or remapping (leading to crashes).

Those are two cases where keeping infamous backward `parents` pointers
of collections in sync is kind of impossible to do... So rebuilding
those relationships from scratch instead.

Fixes e.g. a crash when undoing, then reloading a library, and likely
many more weird ones like that.

Uncovered while investigating T64764.

source/blender/blenkernel/intern/library_remap.c

@@ -368,6 +368,11 @@ static void libblock_remap_data_postprocess_collection_update(Main *bmain,
      * I'd consider optimizing that whole collection remapping process a TODO for later. */
     BKE_collections_child_remove_nulls(bmain, NULL /*old_collection*/);
   }
+  else {
+    /* Temp safe fix, but a "tad" brute force... We should probably be able to use parents from
+     * old_collection instead? */
+    BKE_main_collections_parent_relations_rebuild(bmain);
+  }
 
   BKE_main_collection_sync_remap(bmain);
 }

source/blender/blenloader/intern/readfile.c

@@ -9504,6 +9504,19 @@ static void lib_link_all(FileData *fd, Main *main)
   /* We could integrate that to mesh/curve/lattice lib_link, but this is really cheap process,
    * so simpler to just use it directly in this single call. */
   BLO_main_validate_shapekeys(main, NULL);
+
+  if (fd->memfile != NULL) {
+    /* When doing redo, we perform a tremendous amount of esoterics magic tricks to avoid having to
+     * re-read all library datablocks.
+     * Unfortunately, that means that we do not clear Collections' parents lists, which then get
+     * improperly extended in some cases by lib_link_scene() and lib_link_collection() calls above
+     * (when ome local collection is parent of linked ones).
+     * I do not really see a way to address that issue, besides brute force call below which
+     * invalidates and re-creates all parenting relationships between collections. Yet another
+     * example of why it is such a bad idea to keep that kind of double-linked relationships info
+     * 'permanently' in our data structures... */
+    BKE_main_collections_parent_relations_rebuild(main);
+  }
 }
 
 /** \} */