Added a formal deprecation policy to the project

[orf]

A formal deprecation policy is a good thing to add to this project. Features such as the phone number validation are much better served by dedicated packages like django-phonenumber-field (and libphonenumber underneath), and this is the first step towards that.

My RST skills are not top-notch, so I expect there are some formatting issues that need to be addressed before this can be merged, but the most important discussion is the policy itself. Word on the street is localflavor is moving to a 6 month release cycle, so I propose that we have a 2 release deprecation period before removing features which gives a year for people to discontinue use of deprecated features before their code explodes.

Thoughts?

[benkonrath]

This comes from a conversion @orf and I had at the DjangoCon EU sprints. This project definitely needs a deprecation policy. The biggest sticking point in my mind is formalizing a release schedule so that the deprecation warnings are shown for a reasonable amount of time. I was thinking that we can make a release every 6 months or so which would give users a year to update their code. But that may be too long for users to wait for important changes and updates.

I'd like to get some feedback from the other maintainers and users about the deprecation and release policy. Thanks.

[benkonrath]

@orf The deprecation policy changed a bit because of how Django is now using a "loose form of semantic versioning". I still used some of your copy so I added you to the authors file. Thanks for your help with this!