chore: separate methods in dc_crate into their own modules

[kevaundray]

Description

This is a first try at modularizing the functionality in dc_crate so that we can document and if the right abstraction is applied, test these components nicely.

The traits implementation is quite big, so isolating that large code chunk is also an advantage.

Problem*

Resolves

Summary*

Additional Context

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [Exceptional Case] 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]

Not sure how I feel about this change. I feel like splitting all these functions into different modules like this is probably a symptom of the bigger problem that the name resolution pass is too messy in general.

I do appreciate these being in a "resolution" folder rather than a def_collector folder. We should try to split the two parts of this pass more in the future. The split isn't exact though since there are still some functions like collect_impls in the resolution folder. I'd need to review whether this should be in the def_collector folder instead though since there are cases where some constructs have 3 steps (collect, collect, resolve or collect, resolve, resolve) instead of the normal 2. I think most of the def collecting / name resolution pass could use cleaning up but that'd go beyond reorganization.

[kevaundray]

Not sure how I feel about this change. I feel like splitting all these functions into different modules like this is probably a symptom of the bigger problem that the name resolution pass is too messy in general.

I do appreciate these being in a "resolution" folder rather than a def_collector folder. We should try to split the two parts of this pass more in the future. The split isn't exact though since there are still some functions like collect_impls in the resolution folder. I'd need to review whether this should be in the def_collector folder instead though since there are cases where some constructs have 3 steps (collect, collect, resolve or collect, resolve, resolve) instead of the normal 2. I think most of the def collecting / name resolution pass could use cleaning up but that'd go beyond reorganization.

Yeah I agree with this -- there is a larger issue with the resolution pass. I think to fix it will require multiple PRs that we can flesh out in an issue. I think the re-org is a net positive as it isolates code in such a way that atleast makes it easier to read how a particular language feature is handled and what functions are depending on the resolution of the feature.