feat: Add a relative ordering for attributes

[jfecher]

Description

Problem*

Resolves #6271

Summary*

Wanted to get this before the discussion tomorrow for reference.

Adds a user-defined relative ordering for attributes which orders attributes by annotations placed by the library author of the attribute. This is done with the new #[run_before(attr)] and #[run_after(attr)] attributes which accept another attribute as an argument. Internally, the compiler builds a graph for attributes and topologically sorts it. Then the compiler sorts each attribute usage according to that topological ordering.

TODO:

• Detect graph for cycles, we can use the same method of our existing cycle detection for the dependency graph
• Some miscellaneous errors that are left as todo!()s in the code
• Insert CollectedItems into the program after each attribute group.
  • This is a bit of an interesting case since we should still pool results of each derive to avoid errors there.
  • This also means attributes of the same name will always run in the same grouping. So derived traits are not found by get_trait_impl #6143 would still exist in the case of one attribute applied to several different items, checking for past work. Different attributes will always be on different steps however.

Additional Context

If needed, users can still override an attribute's order by making their own wrapper for the attribute

#[run_after(foo)]
comptime fn my_wrapper(s: StructDefinition) -> Quoted {
    library_attribute(s)
}

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

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

[jfecher]

Superseded by #6326