Use DeprecationWarning subclasses for deprecated features

[Anssi Kääriäinen]

The idea is to introduce new deprecation subclass for each Django version. For example, in current master:

class ToBeRemovedInDjango19Warning(PendingDeprecationWarning):
    pass


class ToBeRemovedInDjango18Warning(DeprecationWarning):
    pass

By using these warnings we can achieve the following:

• Moving PendingDeprecationWarning to DeprecationWarning after release is single line change.
• It will be possible to filter on Django's deprecation warnings without caching warnings from non-django components.
• It will be harder to miss removal of code. After 1.7 is released just remove ToBeRemovedInDjango18Warning. Any code importing that warning will immediately fail. Also, grepping might be a little easier.
• After release, currently introducing a new PendingDeprecationWarning before PendingDeprecationWarnings are renamed to DeprecationWarnings (as part of release procedure) the new deprecatin will likely be moved to DeprecationWarning. But if a ToBeRemovedInDjango20Warning is added it will be really hard to accidentally move that one to DeprecationWarning.
• It will be technically easy to provide for longer than two releases deprecation periods (if we ever want this).

Drawbacks:

• If we use automatic filtering for deprecations, then code currently doing:

warning.simplefilter("always", DeprecationWarning)

will no longer catch Django's deprecation warnings (as we added an entry for warning.simplefilter("default" ToBeRemovedInDjango18Warning) which matches before DeprecationWarning.

I tried this approach in: ​https://github.com/akaariai/django/compare/deprecation_subclasses#L3R18 - The patch is totally incomplete so I will not mark "has patch".