fix(builder): do not check for a Procfile

Some applications do not have a Procfile present before a buildpack
compile step[1]. If a Dockerfile is not present, then the builder
should make the assumption that this app is a buildpack app.

[1]: https://github.com/bacongobbler/heroku-buildpack-jekyll/blob/master/bin/release
fix(registry): store apps as appname

Storing the image in the registry as user/appname introduces a couple
of confusing ideas:

- images are implied to be unique across accounts
- images are owned by one user and one only

Point 1 is incorrect. App names are completely unique across the
entire cluster[1]. Point 2 is incorrect as well because apps can
be shared with the `deis perms` command. Changing the name of the
image in the registry from `user/appname` to `appname` makes the
image names unique across the entire cluster as well as making the
images more easily sharable between users.

fixes #729

[1]: https://github.com/deis/deis/blob/d1e14a6f76789a86f1959ba7bf6057b3abe3b960/controller/api/models.py#L109

BREAKING CHANGES: because this changes the way that applications
are stored in the registry, this is a backwards-incompatible change
with applications prior to this commit. To migrate over to this change,
you'll have to destroy and re-create your apps with the same name
as it was before. The docker layers from previous builds will still
exist in the registry, but the repository names will be changed
to reflect this change.
fix(controller): remove username length validation

This fix that was implemented in #631 was a bit hackish, and was
only used because we stored the images as username/appname in the
registry. The registry has a restriction where the username has
to be greater than or equal to 4 in length. Now that we are not
storing the images with the associated owner's username, we no
longer need this restriction.

reverts #631
fix(client): return 1 on two more error cases

`deis:register` always seemed to succeed in integration testing,
even when it didn't.
Merge pull request #940 from deis/more-cli-return-codes

fix(client): return 1 on two more error cases
chore(builder): update docker to 0.11.1

http://blog.docker.io/2014/05/docker-0-11-release-candidate-for-1-0/
Merge pull request #901 from deis/remove-username-registry

fix(registry): store apps as appname
Merge pull request #876 from deis/no-procfile-check

fix(builder): do not check for a Procfile
fix(test): don't fail if already registered, and pause for builder

Adding a `sleep` call avoids an occasional error when we fire off
`deis create` before the builder is ready, and `|| true` allows the
test to be repeated when the *test* user is already registered.
Merge pull request #944 from deis/builder-docker-0.11.1

chore(builder): update docker to 0.11.1
docs(*): strongly suggest Deis clusters of 3+ nodes

Due to fleet and the Raft consensus algorithm, Deis clusters must consist
of at least 3 nodes, and always be an odd number of members to ensure a quorum
can be reached. This commit updates our documentation to reflect this.
feat(contrib): add changelog script

This script assists in generating the changelog from one release
to another.

To retrieve the changelog from a specific tag to HEAD:

    $ ./generate-changelog.sh <tag>

To retrieve the changelog from two different tags:

    $ ./generate-changelog.sh <from> <to>
fix(CHANGELOG): prep for changelog script

This change is necessary to accomodate for generate-changelog.sh
available in contrib/util. With these changes, it's as easy as

    $ ./contrib/util/generate-changelog.sh v0.7.0 v0.8.0 | cat - CHANGELOG.md > tmp && mv tmp CHANGELOG.md

Which will generate the changes from v0.7.0 to v0.8.0 and append the
output to the top of CHANGELOG.md. The title was redundant, anyways.
style(contrib): make changelog consistent

The precedent is to generate the header of each version in
CHANGELOG.md as a h3 header. This bumps the header generation down
to that level for consistency.
Merge pull request #949 from deis/3_node_minimum

docs(*): strongly suggest Deis clusters of 3+ nodes
feat(Vagrantfile): add fallback to rsync

In some cases (namely when using an encrypted filesystem),
a `vagrant up` will fail due to an NFS error. In these cases,
it is necessary to fall back to rsync to share code between the
local filesystem and the VM.

This commit adds a comment to the Vagrantfile with these instructions
and the necessary config directive.

related to #942
Merge pull request #958 from deis/fallback_to_rsync

feat(Vagrantfile): add fallback to rsync
fix(contrib): seed hosts for CDN workaround

We are seeing lots of slow CDN issues. This is a workaround as
shown in https://github.com/dotcloud/docker/issues/2461#issuecomment-40796941
docs(README): adds troubleshooting information

Detail the most commonly-experienced issues when provisioning Deis,
along with suggested workarounds/fixes. Hopefully this will amount to
a better experience for new Deis users.
Merge pull request #962 from deis/troubleshooting

docs(README): adds troubleshooting information