Removes TraitMap::insert_for_type.

[esdrubal]

Description

Some use cases require the compiler to call insert_implementation_for_type on every call of find_method_for_type.
This would double the compile time of a simple script. To avoid this we removed the TraitMap::insert_for_type. The TraitMap now only stores the original implementations and uses a less restrictive unify_check to get those that match the concrete implementations.

This significantly reduces the TraitMap's size and speeds up the lookup times. On the other hand, it also introduces a type substitution on every find_method_for_type.

A future PR will address the performance of doing type substitutions.

Fixes #5002.
Fixes #6858

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 #6867 will not alter performance

_{Comparing esdrubal/trait_map_without_insert_for_type (447a6e9) with master (5ed7cec)}

Summary

✅ 22 untouched benchmarks

[jjcnn]

I'm not 100% I understand what's going on, but it looks ok.

The two comments I've made are mostly something that looks odd - I don't know if they're actual mistakes. Maybe it would be worth adding comments in those places to avoid future confusion.

[jjcnn]

Shouldn't this be an else if? There's a risk you'll perform two insertions AFAICT.

[jjcnn]

I'm surprised you only need to look at matches[0] and not the rest of the matches.