fix: Make def collector ordering more deterministic

[jfecher]

Description

Problem*

Resolves #2506 partially. The error in the issue is solved since we now always issue an error. The issue before was related to #1122 in which there's no clear ordering we should resolve globals in, so if we reorder the program we can get a different error, but it is at least always deterministic and the program never passes when it should not.

Summary*

To remove as much nondeterminism as possible, I replaced almost all of the hash maps we were iterating over with btree maps. This means in cases where aliases are defined in order the program will always work, but aliases defined backwards or out of order will now always fail to find the type the alias refers to. We'll need a more sophisticated ordering of dependency resolution to fix this.

Documentation

• This PR requires documentation updates when merged.

  • I will submit a noir-lang/docs PR.
  • I will request for and support Dev Rel's help in documenting this PR.

Additional Context

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[alexvitkov]

We'll need a more sophisticated ordering of dependency resolution to fix this.

I'm worried that dependency ordering will not work due to circular dependencies:

struct LinkedList { a: &ref LinkedListAlias }; 
type LinkedListAlias = LinkedList;

I believe this is "semantically valid", although it's pretty dificult to construct a member of A (you have to use std::unsafe::zeroed to create the first instance, and then you can reference it when constructing additional ones). This example is a bit of a stretch, but I'm worried that something like this can arise in a larger program with longer dependency chains.

I believe in the most general case you'd need TypeVariables for the type aliases. I was looking at TypeVariables anyways, since I believe they may be needed to fix #2502, but I don't have a working solution yet.

#2502 is a related problem, but there the conflict is between TypeAliases and Structs, not between the individual TypeAliases - right now if we resolve structs first, they can't contain type aliases, and if we resolve type aliases first, they can't reference structs.

[jfecher]

@alexvitkov in a hypothetical solution with full dependency ordering, any cyclical dependencies we find, we'd report an error for. We'd also have to consider all globally visible items as you mention, so there will no longer be a set "aliases, then structs, then functions" order. It'll depend on where each item is in the dependency tree.

It will also still be possible to create cyclical structures using type variables but you won't be able to actually construct such types.

[jfecher]

I removed the commit adding the fix for #2502, and put up a separate PR instead: #2528

[vezenovm]

Just need those merge conflicts resolved and this looks good to me