datastore: Rationalise set-permissions command

This commit reduces the number of distinct ways of setting db
permissions from three to two (and both use the same paster command),
while simultaneously making it possible to set permissions on remote
database servers without having to manually edit SQL.

The three mechanisms of doing this before were:

1) Run a paster command "set-permissions", which shelled out to
2) A script in `ckanext/datastore/bin`, which shelled out to
   "sudo -u postgres psql ..." and piped in a prefilled version of
3) An SQL template script

The options available for passing through to `psql` did not extend to
setting remote host names, which meant that the only option for
configuring permissions on remote database servers was:

- copy the SQL template script to the remote server
- manually fill in the template parameters (despite the fact they're
  already in the config file)
- execute the SQL

This commit replaces these with two basic ways of setting permissions,
both of which use the "set-permissions" paster command. The script in
`ckanext/datastore/bin` has gone.

You can now either run simply:

    paster datastore set-permissions

Which will emit the correct SQL to STDOUT, allowing you to either pipe
it to a local `psql`:

    paster datastore set-permissions | sudo -u postgres psql

Or pipe it to a remote `psql`

    paster datastore set-permissions | ssh postgres@dbserver psql

Or, finally, you can ask the paste script to connect directly to the
database to run the SQL. This isn't ideal, as it implies you have
network access to a superuser account on the database, but it will make
life easier in development:

    paster datastore set-permissions -- -x

The unfortunate extra "--" is due to the fact that ckan.lib.cli is
insane. It's not possible to provide --options to subcommands without
it, as paster rather wants them all for itself, and will complain if it
sees options it doesn't recognise. By terminating the options list with
"--", paster treats these as extra args, and we can use them in the
subcommand.
travis-install-dependencies: use new set-permissions
datastore: Simplify set-permissions even further

This commit removes the ability for CKAN to execute the permissions
script for you. Why?

1. It's unnecessary. You can almost always pipe the script into a psql
   shell, regardless of the location of your database server. If you
   can't, then the only way that CKAN is going to be able to help is by
   connecting over the network. See point 2.
2. It encourages a setup in which you can connect to your database as a
   superuser over the network. This is a Bad Idea.
3. It adds substantial complication to the set-permissions command.
datastore: Explicitly connect to datastore DB in set-permissions

See comment in set_permissions.sql
Merge pull request #1786 from nickstenning/saner-set-permissions

datastore: Rationalise set-permissions command