dev: handle linter major versions

[ldez]

I tried several approaches, this one is the only one that provides something that works: the previous linter version will be deprecated, and the new one will have a suffix.

linters:
  enable:
    - foo # deprecated
    - foo_v2
  settings:
    foo: # deprecated
      a: 1
      b: 2
    foo_v2:
      a: 1
      d: 2

It will not be usable in every case of breaking changes, but it will work for all linters that create a major version of the module.

usage example:

	return goanalysis.
		NewLinterFromAnalyzer(analyzer).
		WithVersion(2).
		WithLoadMode(goanalysis.LoadModeTypesInfo)

A configuration migration suggestion can be added as a log.

[bombsimon]

I'm not sure I think this is a good approach, or I might be missing something. If we bump the version to WithVersion(2) we will try to deserialize the config to the new format, but this doesn't mean that the users' updated their config? So if a user upgrades golangci-lint to a new version that now uses a different version, that will have the same effect as just upgrading the version directly.

Or is the plan to add one new linter/call per major version? That would add duplication for every configuration and potential indefinite legacy. If this is the goal, wouldn't just add the new version as a new linter be the same without having to put that logic into golangci-lint, e.g. like we did with gomnd -> mnd?

If a version is potentially removed and only vX is left, you'd now have to configure <linter>_vX even though it's the only version which I think is a bit confusing.

There are lots of linters that are not on v1 so it will be hard to know when/why this is used. A linter can change behavior and draft new major releases but keep the same config, now they've diverged between upstream and golangci-lint

I'm not sure what a good alternative would be, but I think I'd rather release a version of golangci-lint warning about versions/configuration to-be-updated. Then the user can prepare for a breaking change without having to spend the time now just because they upgrade golangci-lint.

This approach is new too me so I'll give it some more thought but just want to ensure I understand the suggestion first.

[ldez]

The goal is to have one linter per major version.
The previous linter will be deprecated and will follow the classical linter deprecation flow.