Misleading documentation on choices for a model field

[Mike Fogel]

The ​docs on the choices attribute for a model field currently read "The first element in each tuple is the actual value to be stored..."

This is all true and good for simple model fields, but for more complex ones where the python representation of the field value differs from that in the database, this is at best misleading. An example of this is the ​'hand' example of field subclassing in the docs. For fields like this one, the first element of the model choices field is the python representation of the field value, not the actual value to be stored in the database.

I've implemented a ​pull request that implements a minor documentation change clarifying this, and adds a test to the field subclassing to ensure this behavior is the blessed behavior.

[Tim Graham <timograham@…>]

In 7fd1b35ed794e7d0a2a18f6ac168adba25a7de23:

Fixed #22537 -- Add tests and improved docs for field subclass with choices.

[Tim Graham <timograham@…>]

In bb5c7e4e8d783bf3a2880ab5cf1fa57fd35cd198:

[1.7.x] Fixed #22537 -- Add tests and improved docs for field subclass with choices.

Backport of 7fd1b35ed7 from master