fix NaN problem when starting with an empty data set / zero-sized grid
fix for "Columnpicker control is not fully visible" #923

When positioning the menu make sure the coordinates of the bottom right corner don't exceed window size.
Fixed 'last row overlapped by scrollbar' bug

On a grid without horizontal scrollbar, a resize of canvas that make scrollbar appear will make the last row overlapped by the scrollbar, inaccessible.

This bug appeared at stackoverflow on the question ["slickgrid resize causes scrollbar gap near bottom"](http://stackoverflow.com/questions/13178547/slickgrid-resize-causes-scrollbar-gap-near-bottom), and I found the answer of the user [Aman Mahajan](http://stackoverflow.com/users/2048375/aman-mahajan) as the solution, I just applied the proposed changes here, and the result works like a charm!
Merge remote-tracking branch 'remotes/IagoSRL/master' into k0stya-rowspan

Conflicts:
	slick.grid.js
add planned examples
Merge remote-tracking branch 'remotes/mikemsq/master' into k0stya-rowspan
Merge remote-tracking branch 'remotes/henriks/fixNaN-rebase' into k0stya-rowspan

Conflicts:
	slick.grid.js
ported across from local app: editor API is now all mandatory methods: added assertions to make sure any editor instance fed to slickgrid actually conforms + upgrade all the provided editors.
Set jQuery container to undefined on destroy

Conflicts:
	slick.grid.js
completely nuke the slickgrid instance on destroy: the goal is to have no memory leaks
- significant speed improvement in grid navigation: we always delay the grid `render()` action, which means that the navigation could be very fast indeed... *if* it weren't for the 'little catch' that slickgrid and surroundings at least expects to have a decent DOM node for the active grid coordinate, hence we have 'force' rendering of the node we are navigating *to* immediately, for if we don't then getCellNode() will produce a NULL and you are **toast**: if that were to happen, then you will lose grid focus/activeCell registration and your keyboard control just went belly up.

  Introduce the 'mandatory range' mode of the new forcedRender() function (which is the old 'render()' function with a few **very** specific tweaks to handle both render modes.

- Previously render() was almost always invoked immediately (for obvious reasons); today we have turned `render()` itself into a method which delays its action, depending on the `options.forceSyncScrolling` setting. See the new behaviour when navigating large grids such as the (adjusted) examples/example18-demo.html or examples/example-driven-by-keymaster.html

- Note for the above: the options.asyncRenderDelay has a ridiculous amount to facilitate debugging; this will be fixed in the commit following this one.

- Some JSHint/JSCS happiness edits in the examples

- I intend to use the examples.datasource.js (nee datasource.js) for all or at least most examples so that I can easily 'redimension' the examples to become small or large. Right now this isn't happening yet, but examples.datasource.js has been tweaked to help test the navigation/scroll performance for large grids using the previously mentioned examples.

- added the new Slick.PerformanceTimer component: it is used internally to measure Async PostRender performance (see next item)

- another significant speed/performance improvement: let the async postrender task perform as much work as possibly fits in a single async 'time slot' (of options.asyncPostRenderSlice milliseconds size) instead of merely rendering a single async row per options.asyncPostRenderDelay milliseconds -- which resulted in a very slow updating of these async cells. See for example the examples/example10-async-post-render.html

- further tweaking to enable Chrom/V8 to optimize almost all the code cf. http://www.html5rocks.com/en/tutorials/speed/v8/, http://stackoverflow.com/questions/8423493/what-is-the-performance-of-objects-arrays-in-javascript-specifically-for-googl, http://pic-o.com/2011/12/divlinkedlist/, http://jsperf.com/object-vs-array-vs-native-linked-list --> instead of using `delete` and objects as hash stores, we use arrays and set empty slots to `undefined`. Yes, I know I'll probably get burned for this when we're processing 1M rows or numbers like that; right now I don't (yet), so this is part of the speedup coding action of today.

- navigate() and friends: trivial change; I'm a 'C' guy and the V8 engine is geared towards that mindset; yes, this edit is probably on par with Ameisenvergewaltigung, but it was done to check if the Chrome/V8 debugger/profiler reports actually saw such change (it does). Done as part of the `for..in + hash objects + delete object.attr` to `for(;;) + array + object.attr = null` optimization work.

- now the async delay of the render action is configurable in its delay: options.asyncRenderDelay

- FIX: examples/example18-demo.html crashed badly; the getColumns() API *MUST* deliver an array of column definitions that exists for *all* columns. Fixed.

- FIX: crashes in the getCellValueAndInfo() API when specific options are passed in

- and... using more assert()ions: they help me find bugs much faster, so we'll continue to give slickgrid the same treatment in this as our own private app.

- using MAX_INT instead of Infinity so that Chrome/V8 can observe that the related variables are *always* integer values - which would open up more possibilities or V8 to optimize the code in the JS JIT compiler.

- NOTE: the remaining `for..in` codes, which are flagged by Chrome/V8 as blocking optimization, are flagged by the //@TO-OPT comment marker

- Tweak: using the jQueryUI provided keycode constants for improved readability of the code.

- Added HOME/END key navigation (rudimentary: they just jump to the top/bottom row)
now that deferred render has been optimized & tested, the ridiculous timeout is reset to a sensible value: 85 msecs (which should cause very low CPU load or low key repeat frequencies: as low as 12 Hz)
whoops, missed a var declaration
Merge remote-tracking branch 'remotes/GerHobbelt/k0stya-rowspan' into k0stya-rowspan