add row & column freezing and pinning power

[GerHobbelt]

See also #1 and mleibman#208 for historic reference.

As indicated there, any software engineering solution for this has to render the entire grid in a single canvas:

• this prevents keyboard handling and other UX navigation issues (tab order = prev/next navigation management f.e.)
• not introducing issues like the header/footer scrollpos sync trouble where grid canvas and headers/footers containers show visual lagging between them when scrolling fast on slow/loaded machines.
• latest performance work which introduced the concept of lazy rendering of the canvas has shown conclusively that the existing rowsCache[] mechanism is very able to track/cache multiple chunks of rows. The 'lazy rendering' approach also has shown conclusively that the same goes for multiple chunks of columns: appendHtmlRow() et al may currently be single-range oriented, but having gone through the code at all angles, there's no indication that performance would degrade severely when fragmented ranges or similar directives would be used to update the view instead.
• one problem that I do see with the "single canvas" approach is when you are scrolling "smoothly" and expect a non-frozen cell to hide partly behind a frozen neighbor (clipping the cell view area) when you attempt to simulate similar hiding/clipping behaviour as can be observed in the other grid systems which use a 4-panel approach: there clipping occurs at the panel edge. I'm not sure any CSS solution for this will port back properly to MSIE<10 (which is not a priority for me, personally, but others may feel the need for them)
• I don't yet have come up with an efficient system (fast lookup/edit access from inside the canvas render process) for managing the frozen/pinned rows/columns.
• To keep the API consistent and in line with what we currently have, freezing/pinning should be registered via the columns[] and rowMetaData[] arrays: annotate these column/row specification records in userland code is the way I see it happening (API perspective)