Add willPrepareForDraw to Component.

This is the last moment before the component's element is replace by its
template if he has one.
Remove didSetElement for RootComponent
Move attribute to Component

Mostly this is code from native-control
Functionality isn't changed at this point
Squashed 'packages/mr/' changes from 9fd3d8c..3d616f2

0e92ec9 0.12.5
19a32f2 Remove unneeded files from Q subtree
de6682f Add Q 0.8.12 as a subtree
c72fcb6 Squashed 'packages/q/' content from commit 4c1cc3a
1e9d4f0 Remove Q ready for subtree

git-subtree-dir: packages/mr
git-subtree-split: 3d616f2843268bfceee17f6a7a95ae9ed40b06e2
Update Mr to v0.12.5

Conflicts:
	packages/mr/packages/q/spec/q-spec.js
Remove class attribute
Moving textContent handling to Component.

This doesn't add textContent to all components but allows subtypes to
use this functionality.
Fix a few jasmine matchers
Fix popup-spec
Merge pull request #1100 from Stuk/mr-update

Update Mr to v0.12.5
Merge pull request #1101 from francoisfrisch/native-control

Conflicts:
	ui/component.js
Make Message use correct localization function

And add test
Merge pull request #1102 from Stuk/lzn-fix

Make Message use correct localization function
Allow any bootstrapping script to be used with Montage

Resolves an absolute Montage location so that a relative path
to Montage can be given when using a different bootstrapping
script
Merge pull request #1105 from Stuk/resolve-montage

Allow any bootstrapping script to be used with Montage
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.