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?