change directory structure ascii art to reflect current status (secure_example)

Refactor how we manage secure data, git-identity changes

* I've moved the example secure directory to playbooks/secure_example,
  the directory structure in your secure repo should mirror that in
  secure_example/
* If you run the lms role without a valid git-identity file it will
  fail, there is an empty file checked into the secure_example dir
* Using GIT_SSH env for git checkout, we will also need to use that
  for pip installs that use git if there are private repos in
  requirements.

You may want to deploy more app instances by default to start with.

It's a bummer that enabling VPC DNS hostnames isn't supported by
CloudFormation yet, so we have to do this manual command hack like
we're already doing for ElastiCache. Helpful bit for configuring your
ssh as well.

Install debian and python dependencies for LMS/CMS

* Move debian package list to roles/lms/vars/main.yml
* Move lms_git_repo to roles/lms/vars/main.yml

Return private DNS names that will be resolvale within the VPC. This way
we can define a general SSH config that will work for all hosts.

Some minor ruby role changes

high-level overview of ssh config

moved creation of /opt/www and www user into ruby role

Need to be able to ssh *out* of our hosts to communicate with GitHub for
private repos. Add egress TCP port 22 access to the NATSecurityGroup.

* Cleanups in LMS task
* Add missing debian packages: libgeos-dev, nodejs
* Alphabetize list of debian packages in LMS task

Playbook that installs ruby.

* Create a global variable lms_source_repo to make it easy to update
  where to pull mitx from when mitx moves
* Create global variable venv_base to store location of edx virtual
  environment, defaults to /opt/edx
* Create edx virtual environment to store python modules
* Add tags to LMS and CMS tasks to make selective running and testing
  easier
* Install a long, static list of debian packages, which has been
  manually curated from other edx configurations; this probably needs
  more attention and in the future should probably be divided better
  among various roles.
* Install the list of python packages distributed with the mitx
  repository
* Install some really useful software, namely mosh and tmux

adding license

By default it installs 1.9.3-p374 in /opt/www/.rbenv and gems go
in /opt/www/.gem, which replicates the vagrant box

Feature/e0d/reference architecture

Feature/jbau/env parameterizaton

reduce scaling group minimums to 1 for dev/test

don't require 2 caches for dev/test cases

Eventually we might want to set these thresholds to have better ranges,
but for trying the stack out I say that we shouldn't require an more
than the minimum number of machines.

Also changed top level playbook ymlv var search to follow a path, first
over {{ secure_file_dir }} set in group_vars/all then at
vars/secure_default

parameterize availability zones; reformat templ maps

var empty, so no actual users are created

Added defaults to some of the settings to make it more likely that
someone will get a stack up and running on the first try: deployment
key and environment tag.

Parameterized the availability zones instead of hardcoding them to
us-east-1. Each region has it's own notion of what is primary and
what is secondary, etc. because it seems that not all capabilities
work in all AZ's.  Specifically I got this error when trying to
create a VPC in us-west-1.

> Value (us-west-1b) for parameter availabilityZone is invalid. Subnets
> can currently only be created in the following availability zones:
> us-west-1c, us-west-1a.

For us-east-1 "B" and "C" are still the primary and secondary so EdX
shouldn't be affected. But in us-west-1 primary=A and secondary=C.
We'll have to learn over time what works best for other regions.

Reformatted the mapping sections to make them easier to read.  Hope
you don't mind.  Much terser and easier to eyeball.

Terser overall description.  Removed the "you'll be billed!" warning.