Fix scroll performance for widgets with huge content

[kylefleming]

Test case:
Added a test for a widget with huge content. On my machine, scrolling with either the keyboard or mouse is very slow and every scroll tick takes 5-10 seconds to process.

Fix:
It looks like lines[0] never contains an attr property (correct me if I'm wrong). lines.attr can however, so it seemed the intent was to call lines.attr[0] instead of lines[0].attr.

This check looks like it is related to the widget style attributes, allowing the _parseAttr to be skipped if this.style hasn't changed.

An assumption being made here is that lines.attr will be undefined if the content or width of the widget has changed, thus not allowing a skip to happen.

Another assumption that could be made is that lines.attr will always be at least length 1 if it's been cached (!== undefined). I wasn't sure if that's always the case, but I couldn't find a situation where it wasn't the case. If this assumption can be made, then the check can be simplified to

if (lines.attr && lines.attr[0] === attr)

[iurimatias]

@kylefleming PR merged here embarklabs#5