Fixed #17101 -- Integrated django-secure and added check --deploy option

For background info, please see the [django-developers thread](https://groups.google.com/d/topic/django-developers/t8ybImtdnpM/discussion).
I am strongly opposed to making it default. Yes, for new users it may be the most sensible option. If they accidentally enable it, they'll be on a short lifetime already, so they can resolve it quickly. And I agree that HSTS with includeSubdomains is the ideal scenario.

However, imagine someone who is not in that ideal scenario: they run example.com but there are unavoidable websites under example.com that will not run HTTPS. They currently run Django 1.7 with django-secure and an HSTS lifetime set. The default is to allow those others sites, as includeSubdomains is off. This setup has been tested well, so their lifetime has been raised to 6 months. Then they upgrade to Django 1.8, and suddenly some of their users are reporting connection problems to some of the other websites. By the time the developer figures out what's going on (HSTS-triggered errors are not very clear) there may be many clients that already remember includeSubdomains for 6 months.

When we make justified decisions to break backwards compatibility, we are almost always discussing something that actually breaks loudly. Tests will often catch it. But in this case, just upgrading your Django suddenly breaks a whole bunch of other unrelated sites for many months, without any sign of trouble until users start complaining about vague errors. As this impact is so catastrophic, I think we should definitely default to not having includeSubdomains, even though I would prefer it if everyone in the world would run HSTS with includeSubdomains.

This would be less of a concern if the settings were named differently, so django-secure settings are not used by Django 1.8. Then the silent behaviour means HSTS stops working, which is considerably less catastrophic.