feat(resolve): optimize applying overrides to be efficient

[tyler-french]

What type of PR is this?

Feature

What package or component does this PR mostly affect?

resolve

Enhancements in Resolve Directive Handling

This PR addresses the inefficiency of processing # gazelle:resolve directives. Previously, the system iterated over a slice for each import to find matching directives, which is very inefficient. This PR introduces two major improvements:

1. Transition from Slice to Map: We've shifted from using a slice to a map for storing override configurations. This change reduces lookup time complexity from O(n) to O(1) (or O(length of chain of enclosing dirs containing resolves)).

2. Parent-Child Config Structure: To maintain directory-specific configurations without the overhead of copying maps (which is very inefficient), we've implemented a parent-child relationship in configurations. This structure allows each directory to have its unique overrides while inheriting unmodified settings from its parent. We can't use a single shared map, because this could mistakenly apply directives from one directory to another. regexp overrides are always copied and evaluated inline.

Note on GC: to avoid a really complex object tree, the parent/child relationship skips all ancestors without # gazelle:resolve directives, greatly reducing the complexity.

Note of Regexp: although we need to iterate through these due to the matching logic, we could at least have a map: lang -> []overrides to improve the lookup some.

Data from Uber

We have ~millions of directories to traverse, and approximately 8000 resolve directives.

Profile before changes:

Profile using a full map copy (on small directory), showing the inefficiencies of copying a map each time:

Which issues(s) does this PR fix?

Fixes #1688

[fmeum]

Great stuff!

[tyler-french]

@fmeum Let me do some additional testing to make sure no unexpected behaviors are changed.

[tyler-french]

@fmeum Let me do some additional testing to make sure no unexpected behaviors are changed.

Ok, I ran a bunch of tests and they all seemed to behave as expected. Let me check to see if @linzhp has any hesitations here