Actions :: actionWatcher consume initial events

... safely, by accounting for potential race condition between
registering the watcher and finding previously queued actions
Update the user manager commands.
use short decl for initial and err per code review comments
Uniter API now has WatchActions

This commit adds state/api and state/apiserver endpoints for
WatchActions.
Added extra bits to api/uniter TestWatchActions
apiserver uniter_test TestWatchActions now ensures that the watcher has appropriate results when actions go through
WatchActions no longer discards events
Extra tests on api/uniter WatchActions
Removed spurious WatchActions test
Addressed extra test cases
Testing preexisting Actions case
Now parses unit tag directly
ActionsWatcher now retrieves pending Action ids in the initial event.
Fixed behavior of state/api/uniter test to reflect new Action query.
Addressed missing comments in Actions additions
Merge pull request #141 from binary132/actions-uniter-api-watcher

Uniter API now has WatchActions

This commit adds state/api and state/apiserver endpoints for
WatchActions.
Merge branch 'master' into actionwatcher-initial-events
Updated bodie's test to reflect this PR
Merge pull request #275 from johnweldon/actionwatcher-initial-events

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`.
Fixed up ActionEvents worker/uniter/filter tests to reflect AddAction changes