Dispatch to parents

Ok, here is the bubbling dispatchToParents method, with tests.
Took the liberty to add a little feature: stopPropagation set to true in payload by any ancestor stops further bubbling. If one ancestor needs to catch the event and do the job, why bother its ancestors (and waste time) with useless triggers? 

Cool feature is that since the same object is passed along as payload, data can easily be sent back to issuer or shared between ancestors. Feel free to improve or to let me know if I missed something.
Hmm... the only thing about `event.bubbles` is that it's readonly so people are not in the habit of thinking that it can be set. Just as you write that their habit of using `stopPropagation` as a function will lead to errors if they absentmindedly try using this function on the data payload, would we not be encouraging the same kind of errors the other way around (i.e. in non-Geppetto context this time) by making settable a property that is settable in no other context?

The advantages of `stopPropagation` in my mind are as follows:
- if mistakenly used as a function, will immediately trigger an exception with a clear message; so if there is confusion, it will be short lived
- the name clearly implies that we're doing something, whereas `bubbles` sounds like a value meant to be observed (and that's what it is!)
- term is familiar, descriptive, and unlikely to conflict with application logic when added to the payload.

Perhaps the best way to avoid any confusion would be to choose a term that is not an exact replica of an existing one used in another context? 

How about `stopBubbling`. No confusion possible. Meaning obvious. Action term (verb + complement), not status, therefore conveying the idea that we're doing something by setting this value. Conflicts with applicaiton data in payload unlikely.

Just thought of something else BTW. Suppose we eventually want to stop propagation in a context where it has nothing to do with bubbling. For example, we might want to enhance the `dispatchToAll` function with the same  `stopPropagation` feature for a case where we dispatch to all expecting the event to be picked up by just one context that is hard to reach by other means (e.g. not a parent or an ancestor). There is no garantee that many useless triggers would be saved (intended target may be toward the bottom of the context list), but if we were to stop propagation in this context, we would need a new term as `stopBubbling` or even `bubbles` would be misleading as we're not bubbling. So, here's another advantage for `stopPropagation`! It's less specific, so it allows a wider variety of uses.

Anyway. Sorry for taking so much space to make my point! I'll go with the majority.