Go: Improve diagnostics when no packages are extracted

[mbg]

This PR changes the diagnostics we emit when the extractor's call to packages.Load returns no packages:

• The diagnostic emitted by the extractor has been downgraded from an error-level diagnostic to a warning-level diagnostic. This is because the extractor may be invoked multiple times in e.g. a multi-project repository where this is fine as long as we are able to extract packages for other modules.
• The extractor now stores the number of extracted packages in a JSON file in the database scratch directory. The autobuilder can then load this file.
• If the total number of packages extracted across all extractor runs is zero, then we emit the old error-level diagnostic.

There are also changes to the integration tests to exercise this behaviour:

• The mixed-layout test now includes a module with a Go source file for which no packages are extracted, due to a build constraint.
• There is a new no-packages-in-any-module test which has multiple Go modules, each with source files, but no packages are extracted for any of them.

Alternatives considered

I played around with using the rpc package in the standard library instead of using a file to communicate information between the extractor and the autobuilder, but this produced annoying pop-ups on macOS.

Open questions

• The current file-based approach to exchanging information between the extractor and autobuilder assumes that the extractor is never run more than once at the same time, otherwise there may be race conditions in updating the JSON file. Can we safely make this assumption? If not, we could create a directory instead (similar to diagnostics) and then store multiple JSON files in there for each extractor run.
• Is storing this data in the database scratch directory fine?

[smowton]

To check: as written we'll get a minor regression: manual builds will only produce a warning and no error (except the top-level catch-all something-went-wrong message) if no build extracts anything. Recommended solution: our pre-finalize script should sweep for extractor reports, amalgamate them and turn them into diagnostics. Note this will require a small CLI tweak to allow a pre-finalize script to opt in to execution even when no trap files are emitted, which currently causes that script to be skipped.

[smowton]

extractionresults.go, to avoid looking like extractor/extractor.go?

[smowton]

Suggestion: rather than have a single json file and a read-modify-write process, instead define a distinctive directory name like $SCRATCH/go-extraction-results where the extractor creates a fresh-named file (use a tempfile library for this), then have the autobuilder or pre-finalize step read whatever files were created and amalgamate them. This would mean there are no concurrency concerns except creating a fresh filename, which the tempfile library already knows how to do.

[mbg]

Note that this is already a suggestion in the "open questions" section in the PR description