Show correct way to use runserver

Unless you specify 0.0.0.0:8000 as an argument, runserver will only allow
connections from localhost.  This seems to pair badly with using a Vagrant
private network.
Merge pull request #68 from maurizi/run-tools

Add simple shell script for running manage.py commands
Merge pull request #71 from maurizi/fix-readme

Show correct way to use runserver
Add Packer support

This changeset adds support for creating Amazon Machine Images (AMIs)
that correspond to the types of Vagrant box definitions used in
development. Because we will be making use of the Relational Database
Service (RDS) and ElastiCache (for Redis) in production, services like
PostgreSQL and Redis are excluded from the images.

The 3 AMI types are:

- Monitoring

This AMI contains Kibana, Logstash, and Graphite/Statsite. The goal is
to use this AMI for the bastion host, giving it two roles (bastion and
monitoring server).

- Application

This AMI houses the Django application and maintains pointers to all of
the services it depends on (tile, cache, database).

- Tile

This AMI contains the tiler and maintains pointers to the cache and
database services.

Two other notable additions that were required for Packer support are
private DNS support and a deployment helper to string together
CloudFormation inputs/outputs.

- Private DNS support

Route 53 has support for private DNS. The plan is to use the
`nyc-trees.internal` domain for services available within the Virtual
Private Cloud (VPC). For example, the application server will always be
configured to talk to the cache via
`cache.services.nyc-trees.internal`. This allows AMI creation to be more
flexible in the event that we have to replace the caching cluster.

- Deployment helper

`deployment-helper.sh` contains almost all of the code to connect
CloudFormation stacks. It is a fair amount of Bash, but it defers a lot
of the heavy lifting to the `awscli`.

I originally started down the path of writing tooling in Python with
Boto and Cement, but ran into hurdles due to my Python rustiness and
Cement framework confusion. Also, I don't think that my Python code
would have turned out better than the Python code in the `awscli`.

It would be great to revisit the CloudFormation tooling at a later point
in a way that solves this problem across all Azavea teams.

See the `README` for more details on how an actual deployment would
work.
Merge branch 'feature/packer' into develop
Add django-registration-redux app

This required renaming our "registration" app, to avoid conflicting app
names.

Since only the login views were left once Django Registration views were
removed, I decided to name the app "login"
Add basic templates.

The registration templates were taken from Django Registration Redux's
sample templates.
Remove Django Sites framework.

django-registration-redux and auth.contrib will use the domain name
from the request, which works well enough and is also better for
development.
Change collected static directory to a more obvious name
Remove lint
Use unique email address form for signup.

Also:
Split login/urls.py into a package and move registration urls there.
Fix running the test suite through manage.sh

Apparently the DiscoverRunner needs to be run from the project directory.

Since the Django docs generally show manage.py being used from the
directory it is in, I just changed manage.sh to always run from /opt/app
Use core.User for the auth user model.

Unique email addresses are verified in a full clean method, instead of
with `unique=True` so that we can subclass AbstractUser instead of
AbstractBaseUser.

Also adds `blank=True` to `requested_individual_mapping_at` to allow null
values to pass `full_clean`