don't propagate Guard.listener.ignore_paths to rsync excludes file

guard/guard@306bd4de deprecated the 'ignore_paths' directive
previously available in the Guardfile DSL, in favour of new 'ignore'
and 'filter' directives which accept regexp parameters:

    https://github.com/guard/guard/commit/306bd4de

This means it is no longer practical to propagate the values to
rsync's exclude file, because there is no easy way to convert from
regexps to exclude patterns.

Even if there was, it would not be correct to do it, because 'ignore'
regexps are intended to control the guard listener, which is
independent to the expected behaviour of the rsync invocation.

For example, the user might want certain files only to be rsynced via
the 'run_all' action, and not when they individually change.  This
could be achieved by specifying them in an 'ignore' directive, but not
in guard-rsync's ':excludes' option.

Or the user might choose to compile .sass files to CSS via a
run_on_changes_begin callback:

    https://github.com/guard/guard/wiki/Hooks-and-callbacks

and then rsync only the resulting .css files to the target.  In this
case, the 'ignore' directive could ignore changes to .css files (or
the 'filter' directive could ignore all changes except those to .sass
files) and then the rsync would either exclude .sass files or only
include .css files.
fix indentation
update old comment
invoke rsync via open3

This allows the rsync command to be forked without any quoting issues
which arise through the existence of an intermediate shell process.
make --delete optional
factor out handling of temporary exclude file
rename paths to changed_paths
simplify structure of :excludes option values

The :excludes option expected a Hash whose keys were Regexps.  This
had a number of issues:

  1. It required iterating over the whole source tree to find which
     files matched; this could be costly if the tree is large.

  2. The values were expected to be nil, false, or Procs which would
     transform a matching file path into another file path to be
     excluded.  But this syntax is ugly when you just want to exclude
     a single thing, e.g.

       :excludes => { '.git' => false }

     and didn't actually buy anything useful, since the exclusions
     caused by calling the Proc could be equivalently achieved via
     another Regexp.

  3. It's counter-intuitive since most users already know rsync
     accepts *lists* of exclude patterns, not hashes.

Therefore we simply switch the exclude list to be an Array of native
rsync exclude patterns.  Later we can add back support for Regexps in
case the convenience afforded to the user outweighs the
Dir.glob('**/*') performance hit.
don't strip trailing slash from input path

This well-known rsync behaviour can be very useful in many situations,
so it doesn't make sense to intentionally cripple the way guard-rsync
wraps around it.
allow caller to specify arbitrary excludes

This paves the way for graceful handling of removal events,
where the include/exclude list will be completely different.
allow supplying of arbitrary arguments to rsync
handle removals
DEBUG: show exclude_file contents