Investigate using go/analysis for better performance

[varungandhi-src]

The go/analysis package potentially provides a way of providing indexing that:

• Can reuse results of indexing dependencies (which could be cached by a build system), enabling incremental indexing.
• Can utilize a more efficient encoding for serialized facts, avoiding the need to materialize full ASTs with type information for the full dependency graph, potentially addressing Reduce memory footprint for large monorepos #33

For example, the Uber NilAway tool says this about performance:

It is fast: we have designed NilAway to be fast and scalable, making it suitable for large codebases. In our measurements, we have observed less than 5% build-time overhead when NilAway is enabled. We are also constantly applying optimizations to further reduce its footprint.

[..]

Due to the sophistication of the analyses that NilAway does, NilAway caches its findings about a particular package via the Fact Mechanism from the go/analysis framework. Therefore, it is highly recommended to leverage a driver that supports modular analysis (i.e., bazel/nogo or golangci-lint, but not the standalone checker since it stores all facts in memory) for better performance on large projects. For example, see instructions below for running NilAway on your project with bazel/nogo.

One potential concern is the handling of interfaces. There are already a couple of open issues for those:

• Cross-repo Find implementations does not work when interface is defined downstream of type #64
• Cross-repo find implementations for remote type and remote interface #65

We should make sure that using go/analysis does not regress the existing functionality that we support for Find Implementations.