major update for Ctrl+C/Ctrl+X/Ctrl+V copy-pasta via keyboard:

our own proprietary app has additional code and UI activity which turned out to break copy/paste by keyboard control on Windows machines (at least on ONE Windows machine) due to node focus/keyboard sink issues. I cannot explain why it did work on another OSX machine.

This problem did never surface in the slickgrid examples though: there copy/paste via keyboard always worked...

The solution includes a change where keyboard events are fed to slickgrid externally (i.e. from other DOM nodes) and unhandled keyboard events MAY visit the slickgrid handler TWICE **IFF** slickgrid does not mark those events as 'handled' either. Now the VERY HAIRY bit is that Ctrl+C/X/V keyboard combos ARE detected AND handled by slickgrid (externalcopymanager), but they are NOT MARKED AS HANDLED BY DESIGN: they only work thanks to a trick (creating a temporary TEXTAREA node which is focused shortly) which _requires_ the default browser keyboard handler to kick in as well (after we're done setting things up): you can see this happening in the CellExternalCopyManager where the keyboard events are handled AFTER A TIMEOUT: the new code is augmented to anticipate recursive/looped invocation of the keyboard handler itself as mentioned here: our own app's 'throw key from DOM node X back to slickgrid for further processing' hack now cooperates with the time-delayed copy/pasta keyboard+textarea copyhandler.

The end result is that the current copy/paste code is more robust than before.
- completes the previous copy/pasta commit

- fix crash when getSpans() legally produces NULL instead of a span array.
added onCreate + onDestroy events to the cell selectionrange decorator which allows us to augment the selection overlay rendered by slickgrid.