gopls/internal/lsp: reorder the way we compute diagnostics

Now that diagnostics are not completely free, we must take more care
about when and how (and how often) we access them. Also, we should not
wait for `go mod tidy` before starting to diagnose the initial snapshot.

Fix this by refactoring the diagnostic pass, and skipping expensive mod
diagnostics in code actions. Specifically:
- Simplify diagnosePkgs somewhat, by lifting the logic to determine which
  packages to diagnose / analyze.
- Run go mod tidy concurrently in the diagnostics pass.
- Remove the expensive logic to request all package diagnostics from
  mod.Diagnostics. Instead, let diagnosePkgs report diagnostics for
  files outside the package.
- Don't request workspace package diagnostics when computing code
  actions for mod files. As noted in the comment, I think this logic is
  backwards. For now, this is too expensive.
- Turn guards against the builtin file into bugs: I don't know why they
  existed.
- Invert some logic to simplify the gc_details pass.

This change revealed races inherent in our use of memoize.Promise inside
of forEachPackage: because promises are evaluated on a detached
goroutine, they do not guarantee that their func completes before all
waiters return. Fix this by replacing memoize.Promise with a simple
future cache. This allowed closing over the snapshot, simplifying the
logic significantly.

For golang/go#57987

Change-Id: I2c5fd58db8a1cc0285f32d8a1301a630b9a30b86
Reviewed-on: https://go-review.googlesource.com/c/tools/+/477979
Reviewed-by: Alan Donovan <[email protected]>
Run-TryBot: Robert Findley <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
gopls-CI: kokoro <[email protected]>

Author: findleyr