Make UndoManager asynchronous-operation friendly

The forward march of Promises continues unabated. While adding undo/redo
operations continues to be synchronous, the population of these promises
can now be deferred until later.

For example, when any user interaction concludes, a promise for further
information on how to undo that operation is added to the undo stack.
Again, intent is always considered synchronous even if the
information for undoing that operation is will be known later.

At this point a user can undo this operation even without knowing how
that will happen.

While the UndoManager now only accepts promises, even synchronous
user operations will need to build a promise. In this scenario the
promise will likely be resolved in place, with fulfillment handled in
the nextTick.

From here on the story is the same for synchronous or asynchronous
user operations; invoked undo and redo operations are placed in a queue
and performed in a FIFO manner as soon as possible.

Currently, when asking to undo an operation that has not finished
the operation must be allowed to finish. That is, there's no stopping
the train once leaves until it reaches its destination.

The adoption of promises should make for some approachable
implementation of grouping undo operations.
Stop preserving the original undo label

At this point there are so many opportunities to set a good label
for the redo action there's no need to have this sneaky substitution.

Chances are it will be overwritten by the promise resolution anyway.
Correct spec description so linking works

Otherwise clicking on it in the results doesn't find this spec to run
Added documentation to UndoManager

This is definitely not standard Javadoc and probably more guide-like
than API code doc, but it's here for now.
Make undoManager undo/redoCount observable

The ```get``` attribute alone wasn't going to cut it without
a dependencies attribute, and that's probably going away with FRB on
the horizon.
Added an example usage to the ```add``` method

Nothing too fancy, further information is provided in the undoManager
documentation.
Make label optional operationPromise resolved

Previously there was no way to preserve the original label without
knowing it and passing it along again. Additionally, changing the label,
while nice to be able to do, is probably a fairly infrequent demand.

I don't want the API to be too unwieldy.
Updated to use Lists

Based on feedback from @kriskowal, switching over to use a list.
Update RichTextEditor with async UndoManager

Basically we're putting the burden of creating and resolving promises
on whomever is using the undoManager service.
Reject adding non-promises to the undoManager

We only accept promises.
Correct propertydependencies

undoStack and redoStack are not exposed as public APIs anymore, by
observing them we ended up creating a _undoStack and _redoStack that
overwrote the expected properties we had originally created.

This should be a somewhat temporary change as FRB removes the
dependencies system.

Or this is indicative of a poor detection of existing properties
when creating the underscore-prefixed-observed-property.
Map operationPromise to undo entry earlier

Otherwise we were adding it to the stack and potentially distributing
changes about a new undo operation being available without the entry in
place.
Rename undoManager.add to undoManager.register

The longer this pull request sits open the more I kept thinking I
should change this before I lose my opportunity.
Add operation promise resolution examples
Add comment for flushing operation queue

We can only actively undo what we know how to undo
Add comment for returned promise from undo/redo
Remove unlocalized "Undo" and "Redo"

They are left as an exercise to the user to localize in their own
applications.
Merge pull request #1095 from mczepiel/async-undo

Make UndoManager asynchronous-operation friendly