Remove unecessary migrations blacklisting

[carlio]

From what I can see, the process is:

1. pylint loads the pylint_django plugin and runs load_configuration (or, using compat, we do it) and we add migrations to the linter.config.blacklist : https://github.com/PyCQA/pylint-django/blob/7721691d73a26fea3d4c7e23b90d5cc8ad9c6f96/pylint_django/plugin.py#L13
2. pylint_django loads its list of checkers including the migrations checker, which removess migrations from linter.config.blacklist : https://github.com/PyCQA/pylint-django/blob/7721691d73a26fea3d4c7e23b90d5cc8ad9c6f96/pylint_django/checkers/migrations.py#L159

So basically we add it to the blacklist then remove it almost immediately. I think from the comment that the migrations checker is trying to only remove it for its own checks, but the linter config is global so I believe that this code is unused and has no effect.

Since it probably also interferes with any user-provided configuration in their .pylintrc, and as far as I can tell it hasn't caused any problems that everything checks migrations folders, I think we should remove the code to clean up as I think it's essentially a no-op

[coveralls]

Pull Request Test Coverage Report for Build 1252

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.02%) to 86.967%

---

Totals
Change from base Build 1234:	-0.02%
Covered Lines:	714
Relevant Lines:	821

---

💛 - Coveralls

[atodorov]

So basically we add it to the blacklist then remove it almost immediately. I think from the comment that the migrations checker is trying to only remove it for its own checks, but the linter config is global so I believe that this code is unused and has no effect.

Migrations checker is not enabled by default. You need to --load-plugins=pylint_django.checkers.migrations.

My vote goes against this change. If someone enables both pylint_django and the migrations checker then they end up without the black list anyway.

[carlio]

@atodorov Ah I didn't know that the migrations was a separate plugin, hence my confusion. In that case I agree, this PR is unecessary as the behaviour is currently correct.