Avoid calling go list

[linzhp]

@plakhotnii @codyoss

go list is quite slow because it has to download external dependencies. This becomes more problematic under Bazel execution environment when GOCACHE is not available (bazel-contrib/rules_go#2366). I found all mockgen need from go list is the package path. Why not deduce the package path from source file or directory in mockgen, using logic like:

If GO111MODUE==off: 
   find the relative path from GOPATH
else:
  find the closest go.mod and add the relative path from the go.mod to the module name
  if no go.mod exist and GO111MODUE != on:
    find the relative path from GOPATH

Related to #396

[codyoss]

Hey,

I am not against not using go list but using it fixed a couple bugs for use. The advantages we gained by it were:

1. It is module aware.
2. It works for resolving import paths that are as followed: Have an import path of example.com/foo but the package in foo is actually bar.
3. A special case example of # 2 is projects that use go modules >v1: import path of example.com/foo/v2 where the package in v2 is bar(or this could be foo as well).

If we can find a solution that covers these cases, tests should exist for these, and does not use go list I am all for it. It is not great having to exec something from a binary, but it was a simple solution built into the tooling that fixed some bugs.

I have not looked into this yet, but there could also be extra flags we pass into go list to filter down the amount of packages it scans.