dev: group linter implementation and integration tests

[ldez]

The goal is to group linter implementation and integration tests to facilitate the maintenance and the creation of linters.
It's the continuation of #3100 and #4578.

Each linter has a dedicated package and a dedicated testdata directory.

It allows running all the tests for one linter easily without needing the make test_linters target.

Also, the package test will now contain only "global" integration tests.

The target make test_linters has been renamed to test_integration.

The configuration structures of linters are still inside the config package because of cyclic imports.
It was not my priority for now because it's already a lot of changes.

The file builder_linter.go is still the center of the linter definition, it's intentional: behind the technical problems (cyclic imports) I think it's a good thing to have a central place to reference and document all the linters.

This approach will not be applied to other pieces (e.g. processors, printers, etc.).

typecheck and nolint/nolintlint are special cases due to their nature (not real linters).

Despite the apparent simplicity of this change, it takes me a lot of time to find a working approach, ensure there is no regression inside the tests, and do files move. (I redid my modifications dozens of times)

One commit, one change.

[alexandear]

Is it necessary to rename the make target test_linters to test_integration? This target is frequently used in the documentation and in messages such as #3527 (comment). Could you please share the benefits of using the new make target name?

[ldez]

Is it necessary to rename the make target test_linters to test_integration?

Yes because the target will not run the linter tests.

Could you please share the benefits of using the new make target name?

The "new" make target is the same as before but the linter tests are not run by this target.

Then it's not related to benefits or not, it's just the way it works.

This target is frequently used in the documentation

It's used only one time and it's fixed inside this PR.

[bombsimon]

Really good work, I bet it was tedious so really appreciated! Interesting PR btw, never had this much issues rendering the GitHub diff view 😄

Just a question and dedup suggestion but LGTM! ✅