x/vulndb: compute derived symbols for exported package

[zpavlinovic]

Suppose a vulnerable symbol module/internal.v is reachable in a user program and that there is a derived symbol "module/internal.V" in the vulnerability report. A call stack produced by govulncheck could be something like

main.go calls module/internal.V

The vulnerability is in an internal package and that can be confusing to the user. Instead, we should make the derived symbols be the closest exported symbols of the same module that are in a public package.

For instance, the mere fact that the above summarized call stack exists means that there has to be a sequence of calls of the form module/p.Foo -> module/internal.V -> ... -> module/internal.v. We should thus have module/p.Foo as the derived symbol.

This will also help during report creation where we are interested if a unexported vulnerable symbol is reachable by an exported symbol of a public package of the module in question.

[zpavlinovic]

We should also not include the private symbol in OSV entry if we are able to find some derived symbols.