fix #36104, assign global name during type definitions

[JeffBezanson]

Alternative to #36111. Handling re-definitions is the tricky part. I realized one thing we did before was reset the global binding to undefined if an error happens during type definition, but that is invalid, so we don't do it anymore (with or without this PR). Hopefully that is the only remaining difference with v1.4.

This first checks if the new type object might be compatible with an existing one, and if so throws away the new one and uses the old type and parameters. Then we check that each step (supertype and field types) remains compatible as it runs.

fixes #36104

[JeffBezanson]

Well, unsurprisingly, incomplete types throw a wrench into the works. We have some in the tests just to test that case; hopefully it will not really happen outside of that. I think I will return Any from supertype if the supertype is not set, and give an error from fieldtypes?

[vtjnash]

For soundness, the correct answer for supertype seems would have to be Union{}, not Any. I don't think this PR needs to be changing our handling of supertype, as the current proposal (in #32658) is to not change it.

I think #32658 was adding to the work required to handle incomplete fieldtypes.

[JeffBezanson]

I don't think this PR needs to be changing our handling of supertype

But then it breaks callers, like subtypes.

[JeffBezanson]

This should be ok now. As a bonus, also fixes #21816!
All it sacrifices is that you can't refer to the new type via its module within the supertype expression, e.g.

struct Foo <: AbstractVector{Mod.Foo}

but I expect that to be extremely rare.