Refactor stages

Since we haven't touched the way stages are being defined and run for a really long time lots of stuff has been working around things, calling `run_stages` manually in several places. This resulted in a pretty weird execution order for our build stages.

This pull request changes the run/execution order of our stages as follows:

Before:
```
- script
- before_deploy
- deploy
- after_deploy
- after_success (if succeeded)
- cache push
- after_failure (if failed)
- after_script
```
After:
```
- script
- after_script
- after_success (if succeeded)
- after_failure (if failed)
- cache push
- before_deploy
- deploy
- after_deploy
```
I believe it makes sense to:

* run `:after_script` right after `:script`: that's what the name indicates
* run `:after_success` and `:after_failure` before cache/push and deploy

/cc @rkh do you think this might break caching or deployments in any
way?

Only the `:script` stage will set `$TRAVIS_TEST_RESULT`.