Fix bug 328. Simplify resizing by not recreating everything from scratch. This makes...

Fix bug 328. Simplify resizing by not recreating everything from scratch. This makes it simpler to deal with i328, since we don't have to worry about unremoved event handlers.

Since we're not building everything from scratch, we have to make sure the clipping area is set correctly. Although there's a resetClip method in the HTML5 spec, it's too new. But, man, if we had it things would be great. So instead there's a conditional restore (no restore on the first operation) and a save, for the subsequent restore.

Almost all tests pass, but the ones that test save/restore balances are unsurprisingly broken, as there's one additional save. This can be addressed with calls to g.destroy prior to the assertion, or make a special assertion that verifies there's one more context save than restore.

This has an additional benefit of being slightly faster. Using /Users/konigsberg/git/kberg-dygraphs/tests/resize.html and the following snippet

var start = new Date().getTime();
for (var idx = 0; idx < 500; idx++) {
    g.resize(100 + idx, 100 + idx);
}
console.log(new Date().getTime() - start);

I frequently saw a difference of about 200ms (2200-range to 2400-range.) How much of that was drawing a mildly complex image? Who knows?

I also did some minor refactoring with regards to events, and event method names to make things easier to track.

There may be a need for a plug-in event for resizing.