a plethora of fixes for grid invalidate/update/render, rowpan/colpan support, DataView fundamentals and aggregation/grouping support, examples' updates, etc.:

- fixed several render() glitches which were due to the slightly incorrect order of execution in the render() process which failed to properly update/refresh & complete the viewport at all times when rowspan/colspan cells are involved.

- fixed several issues related to the cellSpan cache, which caused SlickGrid to produce incorrect renders for grids when userland code fiddled with the colspan/rowspan metadata.

- added the new API `getCachedRowRangeInfo()` to help userland code drive and hint SlickGrid & DataView more correctly. The API returns the range of rows which are currently (at least partly) cached. These will be the rows range which must be invalidated if userland code does something drastic (e.g. when changing the grouping of the data: examples/optimizing-dataview)

- fix bugs in resizeCanvas() when the grid is not readily visible.

- fixed the DataView aggregation, grouping and collapsing issues: examples/example-0027-grouping.html now works as expected. Related to #896: one of the culprits was that the `range.bottom` value was *inside* the range (hence the +1 fix worked), while everywhere else a `.bottom` is considered '1 past the end' i.e. beyond the selected range.

- fix DataView lazy aggregation: `lazyTotalsCalculation`; for one, this fixes a crash in examples/example-0027-grouping.html

- DataView recalc(): cleanup: the function only accepts a single parameter anyhow

- DataView: added a new `getOptions()` API so userland code can obtain the actual options for this DataView instance.

- ditto for the GroupDataItemMetaProvider: : added a new `getOptions()` API so userland code can obtain the actual options for this MetaProvider instance.

- all aggregators now use exactly the same checks when the input data is expected to be numeric: we *skip* any NaN in the data, while we *accept* +/-Infinity as valid numbers.

- getCellFromPoint() and getCellFromEvent() now accept a `cfg` configuration/options object parameter where the caller can, for example, instruct SlickGrid to `clipToValidRange: true`, i.e. to always convert the given pixel coordinate to a valid cell/row reference by projecting onto and clipping to the legal grid area. This is an important addition when, for example, clicking in the canvas outside the rendered grid cells should produce a sensible row coordinate at least.

- getViewportWidth(): new API; currently identical to getContainerWidth() but this one at least conveys the correct notion/purpose.

- fix the click/doubleclick/rightclick catching and handling: even when clicking in the canvas but not hitting a rendered cell, then SlickGrid will catch the click and compute the addressed cell coordinate; this is particularly important now that we have delayed render() activity and thus *must* expect grid DOM nodes not to be present *yet* when the user 'aims' at a cell by clicking in the grid canvas.

- fix the click/doubleclick/rightclick event bubbling: do *not* fire the handlers *twice* any more: `signalEventObserved()` is the critical new part for this.

- extra: for the above we also added a new, simple, test page at tests/test-event-modification-transferability.html to check whether browsers support userland modification of the native event object. Chrome does so; we still have to test the others browsers though as signalEventObserved() currently depends on this behaviour where userland code tweaks the native event object and the browser then bubbles up the event including the user tweaks (i.e. browser feeds every registered handler along the event bubble path the same JavaScript event object instance)

- updateCanvasWidth() now implicitly render()s the grid when the changes imply such may be necessary: all the spots where updateCanvasWidth() is called do require a grid update via render() and this is the 'cleanest' way to ensure the render() happens at the right time, consistently. Previously some of the callers didn't invoke render, which had, for instance, the nasty effect that resizing columns (shrinking them) would move previously unseen columns into the viewport area but would *not* trigger a grid render() to update the grid accordingly. Such misbehaviour has been corrected now.

- the column headers are now rendered in a fashion similar to the grid itself, so that 'nested columns' are properly supported by allowing columns to span multiple (header) rows or columns: these characterisitcs are computed and stored in the column definition objects themselves as these attrbiutes:

  + headerRow: the 'header row index' into the `getColumnsInfo().lookupMatrix` 2D array

  + headerRowLayerIndexz: the 'header column index' into the `getColumnsInfo().lookupMatrix` 2D array

  + headerRowSpan

  + headerColSpan

- fix all header DOM node referencing logic to support the 'nested columns' feature by using the overhauled getHeadersColumn(), getHeaderRowColumn() and getFooterRowColumn() APIs internally.

- replaced and corrected the 'level' approach with a proper headerRow approach for the column headers: this way the code is more legible and it also fixes a few glitches alongside.

- fixed bad bug in the grid row render code which would use the wrong formatter for the grid row DOM node itself: now DataView et al are polled for the corect formatter.

- performance/cost: do not register separate drag and click handlers for each header column but instead treat that area like the grid canvas itself: only register single 'delegate' event handlers on the container (`$headerScroller`) instead

- added the new `onColumnCalcWidth` event which allows userland code to produce a suitable column width when the column resize DIV is doubleclicked: this means the grid is requested to 'auto size' that particular column and the built-in approach is merely an approximation; sophisticated grids benefit from having userland code provide a better 'auto sized' column width and then skip (stopPropagation/preventDefault) the built-in approximation.

- refactored the getVBoxDelta() / getHBoxDelta() code (the latter is an entirely new function as a result of this minimal refactoring action)

- grid improvement: use the new `invalidateColumn() / invalidateColumns()` APIs where applicable.

- fix: tighten up the handling of the `setOptions()` API invocation: check option changes and trigger recalculation/rerender activity where necessary.

- fix: `setOptions()` API now returns TRUE/FALSE whether the new options could be set or not; invoking `setOptions()` is illegal and nil when, for instance, a cell edit action is currently pending.

- fix: ensure that the columnsById[] mapping is a guaranteed reversible 1:1 relationship and that the column.id field is always set to something sensible. This fixes the situation where user column definition sets do not carry unique IDs for each of the columns. This is particularly apparent in scenarios where 'nested columns' are employed.

- validationtooltips pkugin: use tooltipster instead of the obsolete tooltipsy library. More work must be done here before this'll actually fly...

- fix crash situation in the RowMoveManager plugin

- updated the jquery-fixclick library

- fixed several examples to ensure they work with the latest SlickGrid incantation

- re-indexed the examples

- more JSHint/JSCS happiness
clean up my act regarding proper grid initialization in Chrome: we ourselves let the app (userland) code take care of this business via using the `options.explicitInitialization` option and calling finishInitialization() until it reports success, but that leaves all the other SlickGrid usage scenarios hanging: now the code runs a timer-based browser poll to ensure the init stage runs to guaranteed completion in case you do *not* have the option `explicitInitialization` set (setting that option implicitly tells SlickGrid that the userland code knows best and SlickGrid then should not bother trying to be 'smart' about this issue).

Either way, we now only fire the onAfterInit event when *everything* that is SlickGrid has really been properly and completely initialized, including the stylesheet setup that is bothering us all so much (see issue #223 and all related and linked there). The essence is that only applying #919 is not good enough; nor does https://github.com/tradingtechnologies/SlickGrid/commit/bf21472f2aa0c1f1b2278db591906c5b349fe557; nor is https://github.com/mleibman/SlickGrid/commit/d10eb9039dcce7b0b37e3a1ce05b44e3c165faa1 (which is the 'lazy get' that starts it all and is a good approach; however, guaranteed init success is only guaranteed when the browser gets some 'air' to include the new style node in the DOM properly, so a timer-based polling approach is called for as a last-ditch effort.

As part of this change we now feed back success/fail return values from any function which depends on these stylesheet access/updates to succeed: the code then uses these return status reports to determine whether a retry/poll is called for. (Again, this is assuming userland code didn't take full control of the situation by setting the option `explicitInitialization`!)
- upgraded the performance measurement utility object (Slick.PerformanceTimer) to provide a more powerful API.

- added a crude test page to measure user activity timings in the browser, e.g. the time it takes the browser to decode a mousedown+up as a click and/or doubleclick. This is mostly relevant for our jquery-fixclick library usage, but landed here as the observation is that click-to-visual-feedback-of-cell-activation is noticably delayed and we're looking into ways to get this resolved without reverting to the old trouble of click vs. doubleclick handling.