Attribution for "insert_backedges" invalidations

Invalidations can be immediate (when an existing MethodInstance gets
invalidated by a new method definition) or delayed. The latter occurs
during deserialization: when a package was built, a particular call
dispatches to Method 1, but when loaded (due to different loading
orders and dependencies) it should instead dispatch to Method 2. These
delayed invalidations are not particularly common, and perhaps because
of this SnoopCompile has never supported them well: they have merely
been dumped to the console during `invalidation_tree`
construction. However, in larger software stacks they seem to become
more common, and can dramatically affect precompilation success.

This simple PR identifies "causes" for such delayed invalidations,
allowing SnoopCompile to determine (in most cases) the particular
definition or deletion that triggered the change in dispatch.

Author: timholy

src/dump.c

@@ -2004,6 +2004,10 @@ static void jl_verify_edges(jl_array_t *targets, jl_array_t **pvalids)
             }
         }
         jl_array_uint8_set(valids, i, valid);
+        if (!valid && _jl_debug_method_invalidation) {
+            jl_array_ptr_1d_push(_jl_debug_method_invalidation, (jl_value_t*)callee);
+            jl_array_ptr_1d_push(_jl_debug_method_invalidation, jl_cstr_to_string("insert_backedges_callee"));
+        }
     }
 }