Refactor and rely on Distribute.

- Use the second namespacing technique from PEP382
- `find_packages()` replaces what we were doing manually
- exclude `test` directories
- add `zip_safe`
Remove custom string conversion in `setup.py`.

Distribute from at least 0.6.26 can handle unicode characters in the package json `description` field (unicode in the `name` breaks). Our custom function however couldn't handle any unicode. It broke with:

```
File "setup.py", line 30, in convert_to_str
    d2[k] = str(v)
UnicodeEncodeError: 'ascii' codec can't encode characters ...
```
WIP - create a common test runner that sets up the Django environment from an expected `env_settings.py` file.
Iterate the last commit. `dev_django.py` is now the hub for running a Django environment with the component's settings; it's not just for tests.

- `run_django_cmd()` can run any Django command
- command line access proxies `manage.py` (so it too can run any Django command)
- add loading error messages
- `test` is a special case where a) we want to allow specific tests (https://docs.djangoproject.com/en/1.5/topics/testing/overview/#running-tests) b) but default to `TESTED_APPS`
Tidying and change of test location.

I'm falling back to the current scheme of `tests/` inside the application directory. (Instead of a root level tests directory/app called "tests" initially introduced in this PR.) The downside is that tests will be distributed in the final code (due to packaging in `setup.py`). The upside is tests are contained. The problem I was having is that a root level "tests" app can conflict when testing multiple Armstrong components in the same virtualenv. If the python path has a path for say armstrong.core.arm_content and you switch to arm_sections, the "tests" app might still be pulled from the earlier path entry. Maybe this is a fridge case; maybe it has to do with my `pip install --editable`; it's easier to keep the current expectations and change them later when I'm moving fewer pieces.
WIP remove VirtualDjango in favor of new `run_django_cmd` and move Fabric tasks into a fabfile.py instead of __init__.py
Replace `reinstall` command with a more flexible `install`
Remove the `pip_install` decorator that automatically uninstalls/installs the component. Replace in favor of an *explicit* install procedure and a decorator that simply halts if the component isn't installed.

I'm in favor of explicit installation and clear messaging. Also I don't believe `pip_install` would have ever worked on a fresh virtualenv. It's hard to test with the multiple avenues of package requirement declaration (between setup.py and the requirements files), but I found that if the package path doesn't exist initially that even after the `pip install`, the component couldn't be imported. Run the exact command again, the path would exist and the command would run fine. I didn't want to add complication of `sys.path.append()` or similar methods.

Coupled with the new `install` task, this is more explicit. It also allows pip installing this component in `editable` mode so that it doesn't have to be reinstalled into the environment every time you make a change and run a Fabric task. (This is similar to `setup.py develop` if we used Distribute.)
Remove package requirements in favor of an "a la carte" model of install when you need it.

This will make environment building faster (and this will be helpful in automatic virtualenv creation during testing). This also gets us away from pinning versions which seems weird especially for a dev tool. I've loosen the Fabric version requirement but left `fudge` the same because it hasn't been updated in a while so if/when it does, it may be something we should control. Also by way of oversight, Sphinx wasn't required and is necessary for the `docs` command.
Drop Lettuce (for now at least) and the no-longer-necessary `get_full_name()`. Refactor `create_migration` to use new `run_django_cmd`.
Refactor `coverage` and `test`.

This actually separates the two commands allowing normal `manage.py test` running as well as `coverage`.
Change coverage directory spec a bit to make it more flexible. (This will be useful for running coverage across multiple test virtualenvs and keeping separate results.)
New feature to remove all Armstrong components (except for armstrong.dev) from the virtualenv. Helpful if you are like me and tend to use the same virtualenv when working with different Armstrong components (perhaps not a great practice).
Remove VirtualDjango!
Fix - literal_eval() needs a string
Revert "Add `assertInContext` method."

This reverts commit 4cda378425c57b874cc08f678fcd3e1b262212a3.
Use the native `assertIsNone()`
http://docs.python.org/2.7/library/unittest.html#unittest.TestCase.assertIsNone
Use the native `assertIsInstance()`
http://docs.python.org/2.7/library/unittest.html#unittest.TestCase.assertIsInstance
Drop this one liner test that can be confused with a native test. Its confusion causing is greater than its benefit.
Add a note to remove this backport code when we drop Django 1.3 support.
Remove `fudge` requirement but keep potentially handy fudge reset behavior.

Individual component's should determine if they require fudge (and what specific version they need).