Actions :: actionWatcher consume initial events

Context
---
When a `watcher` is started it registers with the `state.watcher` to be notified when changelog items matching it's filter are detected.  The `state.watcher` does this by periodically looking through all the new changes in the mongo changelog and feeding appropriate events to all of the registered watchers.

When an `actionWatcher` is first started, we want to not only be notified of new actions being added to the `state.actions` collection, but also of any actions added to the `state.actions` collection before the `actionWatcher` was started.

This is done by querying the state.actions collection in the initialization of the `actionWatcher`, and pre-loading those actionId's into the changes buffer before the watcher loop starts.

This is a common idiom in several of the watchers.


Problem
---
It is possible when the `state.watcher` has been running for more than a few seconds (i.e. in long running tests, or the real world, but not in normal short running tests), that between the time the `actionWatcher` is started, and the `state.watcher` begins notifying the `actionWatcher` of changes, that an action may be added to the `state.actions` collection.

In this case the pre-loaded actionId's could be sent once from the initially loaded changes buffer, and then again when the `state.watcher` detects and notifies the `actionWatcher` of that addition.

However, this is somewhat race-ey.  If the timing is different and the goroutines run in a different order then the pre-loaded actionId's will only be sent down once.


This PR's Solution
---
In this PR we are caching only those pre-loaded actionId's and then filtering subsequent notifications by removing these specific actionId's, since we know they have already been sent.

This is not too bad of a solution; we're not caching *all* of the previously seen actionId's, only the ones vulnerable to this race condition.

The alternative seems way worse, which would be to ask the `state.watcher` what the last changelog number it processed was when we initially register the watcher, and then only pre-loading actionIds that came before that changelog number.  I don't like that option because we're exposing previously internal details of the `state.Watcher` to the `actionWatcher`.
yes, that is intentional.  If filterFn is nil then the WatchCollectionWithFilter acts as though there is no filter.  In fact the WatchCollection method turns around and calls WatchCollectionWithFilter passing a nil fn