added highlight to element on hover by decreasing the opacity of the bac...

...kground elements using a global higlight function

@jebeck can you look at it, i think its ready but i'd like to hear what you think of the code and the resulting interaction.
So the only thing to remark on here is that the tooltips actually work by looking for carbs and bolus events within five minutes of each other (take a look [here](https://github.com/tidepool-org/tideline/blob/master/js/plot/bolus.js#L51), for example), not by exact time, so you'll get both tooltips when the times aren't the same (but only the direct hover target at full opacity):
![screenshot 2014-06-25 14 12 35](https://cloud.githubusercontent.com/assets/1588547/3392352/80a57a24-fcb3-11e3-8178-b2fb6e7098a9.png)
You'll only get both tooltips and both full opacity when the times are exactly the same:
![screenshot 2014-06-25 14 11 44](https://cloud.githubusercontent.com/assets/1588547/3392360/a280356c-fcb3-11e3-8993-d853b4ba36aa.png)

This is mostly an issue in demo data because for real data we're extracting carbs from wizard events, so they are guaranteed to have the same timestamp.

Thinking about future-proofing for when we may have carbs data coming through a separate logging application (or perhaps when we're supporting MDI), maybe we want to use the same time approximate time matching? Or maybe we want to get rid of the approximate time matching altogether - it is a bit of a relic from before we were parsing wizard events.