loading: Try to clean up extension loading a bit (#59863)
The loading code is overall a bit messy. I'd like to add some new
features to it, but I think before I can sensibly do that, some cleanup
is required. This attempts to de-deduplicate the several places where
extensions deal with weakdeps. The logic for extension loading weakdeps
is present multiple times because we support loading extension:
1. By looking at the [extensions] section of the currently active
Project.toml (for loading extensions of the currently active top level
project)
2. By looking at the [extensions] sub-section of the top-level
Manifest.toml (for any extension of a non-toplevel package); and
3. Like 1, except that rather than the env specifying a toplevel
Project.toml, it specifies a directory and we search the second level
for a Project.toml.
This separation is a sensible resolution to the tradeoff of not wanting
to scan all package's `Project.toml`s at load time while also not
forcing a `resolve` for changes to the top-level Project.toml.
Unfortunately, the loading behavior in case 1 currently differs from the
loading behavior of case 2 and 3. In case 1, an extension is allowed to
load any weakdep, in cases 2/3, it's only allowed to load weakdeps that
are also extension triggers. I believe that the missing extra check for
this restriction in case 1 is an oversight.
So, this refactors all that by adding the check to case 1 and mostly
deleting the code for case 3, by just putting the project-file-lookup
code inline at the start of case 1.
Additionally, I've factored out common queries into utility functions,
even when the code itself is simple. The idea is to signal that these
are the same data structure even if they appear in different places
(Project vs Manifest).
Lastly, this makes the following additional behavior changes that I
don't expect to be observable:
In case 2, when loading a non-extension-trigger, don't restart the
search from scratch. The only case in which I could see this causing an
observable behavior difference is if there are multiple versions of the
package in the load path and for some reason the highest priority one
doesn't have the extension (but then how did you load it in the first
place??). However, even in that case, I think the new behavior is
better, because it would get the dep of the version that *did* declare
the extension.
