Remove the PageElement wrapper

[julienw]

Working on #368 led me to take a step back and think more about the PageElement wrapper. What is the purpose of this wrapper? My understanding is that this serves 2 purposes:
1/ Limits the things we can do with a retrieved element. Is this purpose useful in the context of this benchmark? I'd like to argue that it's not.
2/ Provides some common functionality (all the event dispatchers especially). This is useful, but could be provided with a more functional model taking the element as parameter.

Therefore my proposal (for speedometer 4) would be to get rid of the wrapper that brings more complexity than it resolves problems.

Thoughts?

[camillobruni]

Let's have a bigger discussion around this with thorsten as well.

On our end we've been thinking that it would likely make more sense to make the workloads completely independent from the main runner by reporting metrics directly instead of being instrumented form the outside. Using a small shared library between the workloads could easily facilitate this and drop the need for the PageElement (or click events from the outside).

I think the runner-based click events made a lot of sense back when all the workloads were essentially doing the same thing. Once you have diverse workloads there is really not much beyond needing consistent metrics (and some minimal synchronisation).

Some background as to why we originally pushed for the PageElement:

• We'd liked to have experimented more with out-of-process / cross-domain iframes on the chrome side. This would require some sort of serializable interface to consistently run in different modes (same-domain iframes vs. cross-domain).
• The second thing we wanted was native click events (aka from the OS vs the brwoser vs JS) again requireing some sort of accessible format for the interactions.

The last point is likely not going to happen on our end any time soon though.