Fixed #23615 -- Validate that a Model instance's "check" attribute is a ...

...method.

The "check" name is a reserved word used by Django's Check framework,
and cannot be redefined as something else other than a method, or the Check
framework will raise an exception.

This change amends the django.core.checks.model_check.check_all_models()
function, so that it verifies that a model instance's attribute "check"
is actually a method, before calling it and collecting the error
messages.

A test is also provided, and this specific violation is documented and assigned
the id "fields.E008".

This fixes https://code.djangoproject.com/ticket/23615
This is a tough one. My first inclination is to agree with @freakboy3742 that it's simpler to just document "you can't have a field named `check`" - but I also think it's true that by far the most likely fields people have named `check` would be non-descriptor fields, so it's really appealing if we can drastically limit the impact of this backwards-incompatibility by allowing those fields to continue to work. If I had a `BooleanField` named `check` that worked fine in 1.7, I'd be awfully irritated if it started to raise a check error in 1.7.1 (it violates our general commitment that point releases shouldn't break working code).

So I think in the end I would actually come down to "raise an error if the `check()` classmethod isn't accessible, and don't say anything at all - error or warning - if it is". I think in practice this clarifies the error when things would actually break, without breaking _more_ code that is currently working in 1.7.

If we take that approach, I don't think we should dig into all the subtle details in the documents. I think we can just say "It's best not to name a field `check`." The subtlety isn't intended for new code, it's for back-compatibility.