Implement hierarchical trait map and namespace lookups.

[tritao]

Description

This PR implements a hierarchical-based trait map and namespace lookup system while type checking.

Previously we added the concept of lexical concepts, which store all the names in a tree-based hierarchy.
But currently we still rely on a single "global" namespace, which is maintained by the type check context as we go down the tree. Thus, so far, all trait and namespace lookup have relied on looking up in that single namespace.

The main idea here is to be able to just rely on the names existing in the lexical scopes, and walk up those lexical scope chains as we need to lookup any name or trait.

The logic is split into these two commits:

Implement hierarchical trait map lookups.

Implement hierarchical namespace lookups.

This PR still does not remove that cloning, which will be done in a separate future PR.

Checklist

• I have linked to any relevant issues.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation where relevant (API docs, the reference, and the Sway book).
  • If my change requires substantial documentation changes, I have requested support from the DevRel team
• I have added tests that prove my fix is effective or that my feature works.
• I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[codspeed-hq]

CodSpeed Performance Report

Merging #6516 will not alter performance

_{Comparing tritao:hierarchical-lookups-typechecker (3029139) with master (519f208)}

Summary

✅ 22 untouched benchmarks

[sdankel]

nit: I see that this was just moved from another file, but I think we should replace the todo! with something else, like None

[tritao]

nit: I see that this was just moved from another file, but I think we should replace the todo! with something else, like None

I don't think it should return None in this case because that would be a silent failure to the dev. I think maybe an unreachable here probably makes the most sense, and this code is not really designed to be called for parsed declarations.