Properly mark a deleted typemap entry (#27568)

This issue possibly fixes #24951 (or at least the test case by iamed2).
We believe the original code here meant to say either:

    ((jl_typemap_entry_t*)v)->min_world = ((jl_typemap_entry_t*)v)->max_world + 1;

or

    ((jl_typemap_entry_t*)v)->max_world = ((jl_typemap_entry_t*)v)->min_world - 1;

i.e. set the range of applicable worlds to be empty. What happened instead
was that the given typemap entry that was supposed to be deleted became valid
for one particular world and that world only. Thus any code running in that
particular world may try to access the deleted typemap entry (or add a backedge
to it), causing either incorrect behavior or the assertion failure noted
in the issue. One additional complication is that these world ages are being
deserialized, i.e. they may be larger than the currently possible max world age.
This makes this slightly more likely to happen, since the current process
may work its way up to that world age and exectue some code.

In any case, there's not much value to keeping around the deserialized max or min
world, so just mark them as [1:0], as we do for other deleted entries.

Co-authored-by: Jameson Nash <vtjnash@gmail.com>

---

NOTE: This backported commit EXCLUDES additional assertions made by
vtjnash.

(Cherry-picked from commit d9b10f0)

src/dump.c

@@ -2003,7 +2003,8 @@ static void jl_deserialize_struct(jl_serializer_state *s, jl_value_t *v, size_t
             }
             else {
                 // garbage entry - delete it :(
-                ((jl_typemap_entry_t*)v)->min_world = ((jl_typemap_entry_t*)v)->max_world - 1;
+                ((jl_typemap_entry_t*)v)->min_world = 1;
+                ((jl_typemap_entry_t*)v)->max_world = 0;
             }
         }
     }