- add Slick.Keyboard: an object defining names for various keypress codes (enhanced readability); use this one instead of the jQueryUI one as SlickGrid doesn't always require jQueryUI and these codes MUST be present at all times
- performance fixes: only call render() once when handleScroll() is involved as well; no need to run render() twice then

- focus/performance fixes: on click event only set the active cell and focus once, AFTER the custom event has fired -- so that userland event handlers can completely override the set-active-cell / focus behaviour.

- fix: it turns out that jQuery focusin/focusout was behaving 'weird':

  + it got fired when the originally focused row got removed from the cache when scrolling the view: this got fixed by explicitly, but following a strict set of rules (see comments in setActiveCellInternal()), setting the focus when scrolling, etc.. However...

  + both events get fired with some 'weird data' (focusout points at BODY instead of the new activeCell DOM node!) in the el.focus() call which fixed the item above (and in other .focus() calls as well. A lock (movingFocusLock) has been introduced to counter this behaviour and preventing the slockgrid onFocusOu + onFocusIn events from firing (which would create a lot of userland confusion!); instead, as an extra service, onFocusMoved is fired instead: this event lists the from and to DOM nodes (and ditto coordinates if available) when focus travels inside slickgrid.

  + fixed(?) the way editor focus is restored when commit fails on a 'real' focusout (and hence focus must be restored to the editor so the user can fix the invalid adata entry)

- debugging: added names to the anonymous callback functions for legible profiles/debugging stack traces

- performace/FIX: scrollTo() now returns a flag whether it did actually *move* anything or not; consequently all the navigate*() functions now can check this and only invoke render() when scrollTo() repoted some actual change.

  This fixes the new high-performance situation where you scroll up/down by pressing PAGEUP/DOWN key and keeping it depressed: the 'optimal minimal render' (i.e. only the activeCell DOM node, rest of viewport not updated yet and thus still completely white) would 'stick' (keep showing) while you kept the PAGEUP/DOWN key depressed when you were already at the data top/bottom row. PReviously the viewport would only update *after the user released the PAGEUP/DOWN key*. Now the viewport is immediately updated (via delayed render!) when the viewport *stops changing*.

- fix: scrollTo() previously assumed internally that a full re-render() would take place; this is not true in the new high-perf navigation situation, so this assumption had to be killed (no more sneaky setting of `lastRenderedScrollTop` and `prevScrollTop`)

- upon close inspection of the code, re-introduced some JSHint/JSCS happiness where applicable (and this time more consistently than it was done before)

- tweak: getCellFromEvent() now also returns the cell DOM node in the `node` attribute of the returned object `{row:?, cell:?, node:?}`. As a consequence, various events now include this attribute in their data member as well: onClick, onDblClick, onContextMenu (where the latter previously didn't pass any cell coordinate info at all)

- handleScroll() now returns a flag whether a re-render is in order or not; a function parameter (boolean: dontRenderYet) decids whether handleScroll() will invoke render() itself or defer to the caller.

- dragged handleContextMenu() internals into the Year of the Fruitbat (ah, I mean: make the code look and act in line with the other mouse click events; modernization)