Django-iprestrict

- a new management command `add_ip_to_group` has been added. The driving use case is to dynamically add IP addresses, to a _Blacklisted IP Group_ by something like `fail2ban`
- all management commands have been renamed to have underscore delimitation in them (ie. `reload_rules` instead of `reloadrules`, `import_rules` instead of `importrules`. The old commands have been kept for backwards compatibility but they are emitting a deprecation warning

There were some differences detected in our models by the Django migration framework when running on python 3, caused by binary strings used in our models:
- Make all strings unicode in python 2 23
- Generate migrations to reflect the changes

Fixes bug 22 in the recently added geoip support.

django-iprestrict` has been used in production systems for a while now, so it is time to release `1.0.0`.
- Add possibility to restrict IPs by the IP's country 20
- Drop support for Django 1.7 19
- Support Django 1.10 style middlewares 18

**Important:** If you're upgrading and you're still on Django 1.8, please make sure that you specify the `namespace='iprestrict'` when you include the iprestrict urls, as described in the docs:


from django.conf.urls import url, include

urlpatterns = [
... snip ...
url(r'^iprestrict/', include('iprestrict.urls', namespace='iprestrict')),

Bug fixes for some of our views that were failing on Django 1.9+
- Issue 15
- Issue 17

- All setting variables were renamed to have an `IPRESTRICT_` prefix. Please update your settings files accordingly. Currently a deprecation warning is shown, but in a later version support for the old settings variables will be removed.
- Additionally `IPRESTRICT_DONT_RELOAD_RULES` has been changed to `IPRESTRICT_RELOAD_RULES`. The new variable is the inverse of the old one so if you had it set to `False` set it to `True` and vice versa.
- When `django-admin.py reloadrules` is called but `IPRESTRICT_RELOAD_RULES` is `False` show an error message instead of pretending that the reload might happen
- Denied requests are now logged at `WARN` level instead of `INFO` level
- Fix for using timezone aware datetimes when `USE_TZ` is enabled in Django