Add Target class to participate in events

ActiveTarget indicates the logical target the user is focused on much
as the document.activeElement indicates the element the user is
focused on.

activeElement may differ from activeTarget as the activeElement may
have no associated component.

All components are Targets.

This hopefully clarifies some of the half-baked attempts at articulating
this need as evidenced by the component's "acceptsDirectFocus",
and the "parentProperty" to facilitate pointing to the next target
candidate, in addition to a few one-off implementations manually
doing the work of finding the activeComponent.

Specifically, anywhere where we dispatched an event on a component the
user was focused on instead of where the event happened will now be
easier.

The eventManager also provides two new APIs that leverage this new
information, `dispatchFocusedEvent` and `dispatchFocusedEventNamed`
that match their less focused brethren in purpose while using the
activeTarget as the proximal target of the event.

Targets also provide a `nextTarget` property which is used exactly as
the `parentProperty` was to direct distribution of events through a tree
of target candidates.

The implementation thus far reuses the activationEvents concept which
the EventManager already manages. An alternative implementation
could derive the activeTarget from the activeElement and even
drive the prepareForActivationEvent system through focus alone.

That remains a possibility whereas this implementation minimizes
churn by using as much of the existing machinery as possible.
Move eventDispatching off Object.prototype

I didn't even know they were there, now they're on Target. Anybody that
ever plans on being able to be the proximal target or a target during
event distribution will need to be a Target now.

I've found a few places in my limited testing where this was necessary
to introduce in a few object's prototype chain.

The specs are a daunting work in progress.
Correct a few objects trying to dispatchEvents

Object.prototype no longer provides this functionality, it's moved
into Target.
Rename as testMontage as testTarget for clarity

The intent being that the Target object used as the prototype has come
from the test environment, not the test suite environment.

This used to actually be a Montage object, not a Target.
Add specs for activeTarget concept

Always a worthwhile endeavor as I figured out I wasn't actually using
nextTarget to find the next target if the original didn't acceptFocus.

Anyway, now we have tests built on top of the hands-on playground so
there should be enough to get a feel for how this system works.
Ensure a component's nextTarget can be set

Of course, by default if there is non specified, use the
parentComponent. I'm purposefully going to prevent breaking the chain
if the nextTarget is falsy on components.

There is also now an example of redirecting the event target chain off
off of the componentTree
Differ event target path building strategies

Events originating from DOM targets remains DOM only in considering
target candidates.

Events originating from a Target uses the nextTarget facility in
considering target candidates.
Switch key-composer over to dispatchFocusdEvent

This is a half-baked transition; just enough to make sure it works in
theory. It's certainly not an exhaustive switch. I think the API may
warrant some changing with these results as usage of the keyComposers
is still confusing.
Visualize the application level event target chain

There ae better visualizations of course but this is a decent start.
Move eventListener API off of Object.prototype

More victories in consolidating dispatching responsibilities to
the Target; now the listener registration can be centralized here seeing
as these are the only objects that should be dispatching.

This does elevate Target to be a more vital concept, but it's sensible.

This may prove more disruptive than relocating the dispatching alone,
I haven't rigorously tested.
Rename acceptsFocus as acceptsActiveTarget

I don't want to conflate the concept of focus and the concept of being
activeTarget.
Add API to Target around becoming activeTarget

In particular I've added a rough menu/toolbar example that uses these
new API hooks to preserve the original activeTarget while allowing
the menuItems themselves to become the activeTarget for handling
keyboard events.

While we may have some opinionated components that do otherwise,
this activeTarget system doesn't limit interesting multi-input
scenarios.
Merge branch 'edge' into active-target

Conflicts:
	composer/composer.js
	core/application.js
	test/run.js
	ui/check-input.js
	ui/native/button.reel/button.js
Merge branch 'edge' into active-target

Conflicts:
	test/events/object-hierarchy-spec.js
Merge branch 'edge' into active-target
Merge branch 'edge' into active-target
Merge branch 'edge' into active-target
Add labels to test for easier following

It may not be obvious what the identifier of each component is
Request a draw upon creation

Otherwise the component never draws as it has no template and really
has no reason to draw. This meant the listener was not being installed.
Move target info panel out of the way

Helps that it doesn't jump the page around as it changes vertical
offset based on its content, and it's always visible.