refactor(Focus): Use handleEvent instead of arrow functions

[bigopon]

This PR replaces 2 arrow functions: focusListener & blurListener by handleEvent, leveraging event target interface for lower memory consumption.

[EisenbergEffect]

Ok, this is awesome. I didn't even know about this API option. @jdanyow Can you think of any reason not to do this? @bigopon What if we also removed the extra methods and just inlined the behavior in the switch statement?

[bigopon]

Inlined. But I don't why the whole content got blown away and replaced, despite being the same ... Is that an issue ?

@EisenbergEffect The API also motivated me to propose aurelia/binding#604, where in each Listener binding, we use the instance itself as listener instead of a newly created arrow function. That proposal contains 2 changes, in which 1 is breaking (Allow multiples events attached on the same element, 1 in template declaration, and 1 in element consumption). In my opinion, maybe just pull in the changes for API usage first, and leave the other for future discussion.

[EisenbergEffect]

@bigopon It looks like it could be some sort of whitespace issue.

@jdanyow Can you review this and let me know if you see any issues. This looks like a good change and something we might be able to leverage in other places as well.

[bigopon]

@EisenbergEffect @jdanyow I've also put in observer locator to address #273

[jdanyow]

The API is new- it's from aurelia/binding#620

Add ?w=1 to ignore whitespace differences on github. For example, here's this PR: https://github.com/aurelia/templating-resources/pull/291/files?w=1

[jdanyow]

if (this.hasSubscribers = this.observerLocator.getObserver(this, 'value').hasSubscribers())

I don't think we can use this kind of logic to determine whether to add event listeners. Assumes binding order.

[bigopon]

I've reverted all the changes. Couldn't think of binding order when attempted to fix that