Description
Both of these checkers inspect and rely on Django being present and configurable, and so there is a bit of overlap in their functionality. Rather than having two similar "setup" methods to validate that Django can be used, they could probably be rolled into one single PylintDjangoChecker.
This would mean the pylint_django plugins simply loads many checkers in a similar way to pylint (https://github.com/PyCQA/pylint/blob/master/pylint/checkers/__init__.py#L62) rather than loading everything when the plugin is loaded, so it might make the code a bit cleaner to do it this way.
The foreignkey checking ran into this issue in that it tried to load transforms before the plugin was completely set up, which meant there was no way way to test if Django was configured before the Django features were used. While for most things such as transforming model field types, this isn't an issue, we may as well have consistent loading and configuration behaviour even for situations for which it might be overkill. This would hopefully lead to the plugin being a bit more organised and accessible to anyone who wants to add features or fix bugs!