Event Processing Pipeline (WIP)

This introduces a pipeline for processing events before forwarding them to the Event channel.

* The trigger pipeline step is used to filter **create, modify, delete, rename** events. It's logic is an extraction of the code that was in `purgeEvents().`
* The hidden pipeline step filters hidden files and directories
* The pattern pipeline step filters based on shell file pattern, eg. "*.go,*.c"
* The throttle pipeline step filters trailing events on the same file
* The logging step logs all new events (and the verbose flag is used elsewhere)

Initially I avoided changing the exported API, but since I began adding additional pipeline steps, I've started to implement changes as originally proposed in #64. 

The tests pass on OS X, Linux, BSD and Windows and I have been testing it from Looper as well. I have seen some intermittent failures in `TestFsnotifySubDir` on OS X (#67).

* [ ] Update usage information in README and example_test (GoDoc). 
* [ ] how to handle fallbacks when pipeline (was fsnFlags) was not found in the Watcher structure on Linux/BSD

### Event

* [ ] add IsDir() to Event interface/FileEvent implementation (do a separate PR) **NEXT**

### Recursive

* [x] The auto watch pipeline step needs to watch a folder with the same pipeline/options
* [ ] Need to handle errors from the auto watch (put on the Error channel?)
* [ ] Remove watch recursively (the externalWatches addition to kqueue may help here?)
* [x] Tests

### Hidden

* [x] does Windows need special handling for filtering hidden files/folders
* [ ] handle hidden edge case, request a watch on a hidden folder with Hidden:false
* [ ] make hidden option more clear (Keep/IgnoreHidden?)

### Throttle

* note behaviour and configuration may change to match FSEvents adapter in the future #54

### Verbose

* [ ] determine more specifically what it should/shouldn't log
* [ ] should it work with other logging packages? can we add that later easily enough? (just more Options)

### API

* [x] should the notifier interface be public and what should it be called? Either way the Event channel must remain a type of FileEvent to avoid breaking changes.
* continue discussion of public API #64 before merging to master? come back to channels vs. iterators and other API changes as part of the move to os/fsnotify.

### Tests

* [ ] Keep current integration tests for previous API and write up new ones to test against new APIs.