Use bin/setup from Travis

In order to test the executable documentation provided by bin/setup, we
should use bin/setup from CI.

Anything that is inappropriate for a CI environment is tucked behind a
check for the CI environment variable, which is present on Travis, Circle,
TDDium, etc. We should strive to mimize what's in here.

This necessitated breaking up the single call to `rake dev:prime` (which
has `db:setup` as a dependency) into a call to `rake db:setup` followed by
a later call to `rake dev:prime` if we're not in CI.

A change was also made to the foreman installation. It wasn't clear to me
why we needed to error when Foreman wasn't installed when we could just as
easily install it.

I transitioned checks for gem presence to use `gem list --installed` and to
omit the `--no-document` flag. This flag should be decided by the user's
`.gemrc`.

The script was also changed to use a bash shebang because `&>` is not POSIX
compliant.
I don't feel strongly but would like to get this PR merged soon so I can include it in a new gem release.

> On Nov 24, 2014, at 1:21 PM, Joe Ferris <notifications@github.com> wrote:
> 
> In templates/bin_setup.erb:
> 
> > -  printf 'See https://github.com/ddollar/foreman for install instructions.\n'
> > -  exit 1
> > +# Only if this isn't CI
> > +if [ -z "$CI" ]; then
> > +  if ! command -v foreman > /dev/null; then
> > +    printf 'Foreman is not installed.\n'
> > +    printf 'See https://github.com/ddollar/foreman for install instructions.\n'
> > +  else
> > +    # Pick a port for Foreman
> > +    if ! grep -qs 'port' .foreman; then
> > +      printf 'port: <%= config[:port_number] %>\n' >> .foreman
> > +    fi
> > +  fi
> > +
> > +  # Add dev-specific seed data
> > +  bundle exec rake dev:prime
> Do we have any projects with really slow seeds? I've never been on a project where they take more than a few seconds after bootstrapping the schema, which is negligible compared to things we do like bundle install or pushing to Heroku.
> 
> Having broken seeds means development is broken, so it seems intelligent to try and catch these on CI during pull request review.
> 
> —
> Reply to this email directly or view it on GitHub.
>