Installs `parity`

* `curl` / `heroku-toolbelt` / `pg_restore` should all
  already be available
Install foreman on OS X

This uses installer(1).

On GNU we already install `heroku-toolbelt` using apt, and that package
has a dependency on the `foreman` package.

We install this via installer(1) instead of gem(1) so that it remains
regardless of the development Ruby setup.

We install this via installer(1) instead of from the `Gemfile` so that
it remains regardless of what other developers do on the project (as
described by David Dollar).
Use root to run the installer(1)
Switch to launchctl for Postgres

`brew services` is no longer supported:

https://github.com/Homebrew/homebrew/commit/c0b99c031fec0a2096b85a458d7b42e3627560d8

* Fixes https://github.com/thoughtbot/laptop/issues/93
* Fixes https://github.com/thoughtbot/laptop/issues/243
* Idempotently creates Postgres database cluster and starts (or restarts)
  Postgres.
Log the output of the script to a file and stdout

Thanks for the implementation, @pbrisbin.
Update prerequisites in README

Homebrew's install script checks whether the command line tools are installed,
and, only if necessary, will run `xcode-select --install`.

https://github.com/Homebrew/homebrew/blob/go/install#L162

The test they are using depends in part on a heuristic:

https://github.com/Homebrew/homebrew/commit/afa45493af041e3357d9cff64dea085e88eed251

I confirmed that it works on a clean 10.9 install.

We also should not instruct the user to run `sudo xcodebuild -license` at all.

Here's why:

The `xcodebuild program` isn't included in OS X Mavericks. When you run
`xcodebuild`, you're actually finding one of 83 shims found in `/usr/bin` that
are included in Mavericks. These shims are an important part of how the
`xcode-select` mechanism works. When the command line developer tools have not
been installed, invoking any of these shims won't do anything other than prompt
you to install the command line developer tools:

    $ xcodebuild -license
    xcode-select: note: no developer tools were found at
    '/Applications/Xcode.app', requesting install.
    Choose an option in the dialog to download the command line developer tools.

(And, the GUI install dialog is presented.)

Of course, since the real `xcodebuild` program isn't actually available, it
doesn't make sense to try and use it to accept the Xcode License Agreement.

Instead, go straight to installing with `xcode-select --install` (xcode-select
comes with OS X Mavericks and is not a shim):

    $ xcode-select --install
    xcode-select: note: install requested for command line developer tools

And, the exact same GUI install dialog is presented (prompting the user to
either "Get Xcode" from the App Store or immediately "Install" the command line
developer tools).

For more about `xcode-select` and it's shims, see `man xcode-select`.

This also removes redundant Vagrant setup instructions and capitalize Vagrant.
Don't upgrade a brew that is already up to date

Fixes https://github.com/thoughtbot/laptop/issues/257

On a clean OS X Mavericks, Laptop outputs an error message towards the end of
the install script when `brew_install_or_upgrade` is invoked for OpenSSL:

    Upgrading and linking OpenSSL ...
    Error: openssl-1.0.1h already installed
    Linking /usr/local/Cellar/openssl/1.0.1h... 1139 symlinks created

The current version of OpenSSL was installed earlier as a dependency of
PostgreSQL. In general, a similar error will be logged whenever
`brew_install_or_upgrade` is called for an installed package that's already up
to date.

Currently, Laptop discards the error exit code of `brew upgrade` as follows:

    (brew upgrade "$@") || true

In addition to logging an error when there isn't truly an error, this approach
can cause real `brew upgrade` errors and potential bugs in Laptop to be masked
(e.g. Homebrew formula build failures or Laptop mistakenly invoking `brew
upgrade` for a package that isn't actually installed).

I think a better approach would be to check whether the installed package is the
same version as the current Homebrew formula before attempting `brew upgrade`.
Make brew_install_or_upgrade work with aliases

Fixes https://github.com/thoughtbot/laptop/issues/258

The following doesn't behave as intended:

    brew_install_or_upgrade 'postgres'

because "postgres" is an alias, not the full name of the formula. The actual
formula name is "postgresql".

The first time `brew_install_or_upgrade 'postgres'` is invoked it works as
expected — `brew install postgres` is run. Additional invocations result in
`brew install` instead of the expected `brew upgrade`.

The `brew_install_or_upgrade` function uses `brew list -1` to obtain a complete
list of installed packages, and these package names will be the actual package
names. So, grepping for an alias (with the `-x` option) won't match:

    $ brew list -1 | grep -Fx postgres

Note that there's no output, even though PostgreSQL is installed. Using the full
package name behaves as expected:

    $ brew list -1 | grep -Fx postgresql
    postgresql

Rather than passing on the first argument to `brew_install_or_upgrade` to the
`brew list` commands, the argument should first be expanded to the actual
package name.
Test whether Homebrew formula is installed

More readable and testable this way.
Fix warning when linking already-linked OpenSSL

Fixes https://github.com/thoughtbot/laptop/issues/259

Laptop raises the following warning on `brew link openssl ` when OpenSSL has
already been linked:

    Warning: Already linked: /usr/local/Cellar/openssl/1.0.1h
    To relink: brew unlink openssl && brew link openssl

I think the resolution is straightforward: follow Homebrew's recommendation and
`brew unlink` before `brew link`. I verified that `brew unlink` exits with
success even if the formula wasn't previously linked as would be the case the
first time Laptop is installed.
Add idempotent brew_launchctl_restart function

Fixes https://github.com/thoughtbot/laptop/issues/260

This is a soft error that occurs when Laptop is run and PostgreSQL isn't
currently loaded by `launchclt`, e.g. on the first run of Laptop:

    Starting Postgres ...
    /Users/wellmade/Library/LaunchAgents/homebrew.mxcl.postgresql.plist ->
    /usr/local/opt/postgresql/homebrew.mxcl.postgresql.plist
    launchctl: Error unloading: homebrew.mxcl.postgresql

The fix would probably be to check `launchctl list` to see if the service is
already loaded before calling `launchctl unload`.

This small added complexity probably justifies a function for running
appropriate `launchctl` commands. Homebrew has a strong convention for the
naming of `launchd` plists: "homebrew.mxcl.FORMULA_NAME.plist", e.g.
"homebrew.mxcl.postgresql.plist" and "homebrew.mxcl.redis.plist". This likely
makes a function to do the `launchctl` work fairly straightforward.
Upgrade to latest version of Node.js

We can future-proof the script little more by setting `node_version` to 0.10.
NVM will automatically install the latest 0.10.x version:

https://github.com/creationix/nvm#usage
Drop support for Snow Leopard

* Snow Leopard was released in August, 2009 (about five years ago).
* Yosemite will be released in a couple of months.
* We support the last three versions of Ubuntu, so this is a little more
  consistent.
* Use the same format as the Linux "Requirements" section for consistency.
Link README to programs that Laptop installs

So that users can learn more about them.
Clarify OS X support
Add compatibility for Bash 3.x

The `|&` is new in Bash 4, which is not the default on Macs.

Given that Laptop is meant to be run on a fresh machine, `2>&1 |` is preferable,
since it'll work on the Bash 3.x, which is what comes installed on new machines.
Repackage base boxes, used by rspec tests
Remove support for EOL'd ubuntu-13.10 (saucy)

Saucy reached its EOL on 7/17/14.

https://lists.ubuntu.com/archives/ubuntu-announce/2014-June/000185.html
Make `brew_is_upgradable` mac function more robust

Rely on logic of `brew outdated` to decide whether a brew is upgradable.

Fixes #276 and #282:
* https://github.com/thoughtbot/laptop/issues/276
* https://github.com/thoughtbot/laptop/issues/282
Don't redirect stderr to /dev/null

`&>` redirects both `stderr` and `stdout`.
`>` redirects only stdout.

Use `&>` when we explicitly want to ignore/discard error messages,
which is rarely.

`command -v` outputs only stdout.
So, `>` is appropriate because there is expected `stderr` output.
In the rare case that command fails,
we want the reason printed.