Remove incomplete manifest package load fallback. Add instantiate suggestion to error

[IanButterworth]

When packages are not instantiated at all, but present in the active environment, you get a helpful

julia> using Images
ERROR: ArgumentError: Package Images [916415d5-f1e6-5110-898d-aaa5f9f070e0] is required but does not seem to be installed:
 - Run `Pkg.instantiate()` to install all recorded dependencies.

but in some condition where some but not all packages are instantiated in some form you get a verbose very long mess of warnings.

Seemingly the tooling intended for dev juggling in #27932 is being hit in non-dev situations

as seen in https://discourse.julialang.org/t/the-endless-packages-to-add-as-as-a-dependency-or-to-resolve/70450

The loading code does already intend to make warnings manageable by suppressing repeat warnings, but the flags aren't sent to the child compilecache workers, so they think they've not been seen before.

I once managed to replicate the issue above by checking out the repo in question, activating it and using Images without instantiating first, hit the error, then fixed it with a single instantiate.

---

This PR

• (a bandaid) adds a suggestion upfront in that code path that the environment might not be fully instantiated, and that Pkg.instantiate() should be tried first.
• (a bugfix) passes the existing warning state helpers to the nested compilecache workers, to make the suppression of repeat warnings work through code loading
• Reverts RFC allow packages to fall back to finding UUID in project if not in deps of manifest #27932

Ideally it'd be good to figure out why #27932 gets hit and avoid that.

I don't have a reproducer to test this out

Related to #38545

[KristofferC]

FWIW, #27932 was introduced at a time where projects were completely new and people were quite frustrated with not being able to load their package. So I would say it was a necessary "smoothener" in the transition to project-centered package loading but by now it might be a good idea to just remove that fallback.

[IanButterworth]

That sounds good actually. I'll turn this PR into that

[IanButterworth]

Now reverts #27932 but keeps the new first bullet in the suggestion

[IanButterworth]

@KristofferC What do you think? Give it a go for 1.8?

[IanButterworth]

If now's not the time for this, I don't think it needs to stay open. Easy to reopen

[vtjnash]

I think this was essentially approved (and closes #42873). Sorry it got forgotten and nobody remembered to comment that it was good to merge. This code (that this removes) definitely injects a lot of bugs into the child processes, and only ever was possibly functional for the main process.

[IanButterworth]

@KristofferC just checking you agree?

[KristofferC]

Sure, let's try this.

[IanButterworth]

@KristofferC @vtjnash

An example of what this breaks

https://github.com/timholy/Revise.jl/runs/5100224366?check_suite_focus=true#step:7:247

cc. @timholy

[timholy]

For the record, that breakage is a test of "does Revise behave the same as Base?" If Base is changing, Revise should too, and in this case I'd just not run that test on Base.VERSION >= v"1.8.0-DEV.1451". But of course such changes are worth bringing to folks' attention.