Upgrade the Go version to v1.18, and x/tools to v0.1.11. Support generics better.

[guodongli-google]

Address the differences related to the new SSA format.
Remove errors/warnings on generics types, and add unit tests.

Fixes #323

It's a good idea to open an issue first for discussion.

• Running against a large codebase such as Kubernetes does not error out. (See DEVELOPING.md for instructions on how to do that.)
• Appropriate changes to README are included in PR

[guodongli-google]

Have no idea why the linter "addlicense" fails since it succeeds locally.

[PurelyApplied]

I think we should signal to the user somewhere that generic support is not enabled. That could be in the README inclusive-or as a message when these skip blocks are hit. But it seems like a gap in coverage that a user might be expecting otherwise.

[PurelyApplied]

Is this actionable? I thought // indirect imports were the result of a direct import not building with a go.mod that details explicit dependencies, so the consumer has to choose explicit versions. But other than removing our direct dependencies, I don't think we get to clean up the indirect ones, do we?

I think having them grouped separately is cleaned up enough.

[guodongli-google]

These indirect imports are actually produced automatically by go mod tidy, and I don't have a better way to handle them now.

[guodongli-google]

I think we should signal to the user somewhere that generic support is not enabled. That could be in the README inclusive-or as a message when these skip blocks are hit. But it seems like a gap in coverage that a user might be expecting otherwise.

Agreed. However warning each generics usage will be too much, and it is better to specify it somewhere else, e.g. in a README file.
There are follow-up CLs where I want to handle the generics better, e.g. through the "InstantiateGenerics" mode. Nevertheless, the full support won't be available soon. I'd let you recommend how to put in such a message.

[PurelyApplied]

I'm sorry to have let this get so stale.

I saw Tim's #327 and have started a thread there, but to summarize: it would be nice to fold this and that PR into each other. I can go either way on either requiring 1.18+ vs Tim's init() approach to set the expectation between interface{} vs any, but like this PR's addition of tests (which I suppose require 1.18).

[sjbarag]

Looks like most of this landed via #327. Are there still generics-support gaps?