Add support for dashed lines (SkPaint setDashPathEffect / clearPathEffect).
Default to 3d2d windows, which uses OpenGL for the blit path.
Seems like there are colorspace transformations happening after the blit,
presumably the NSView / etc is in a device independent colorspace that is
transformed into the screen colorspace.  For now avoid this whole thing and
print a warning about 2d windows.
Upgrade to Node at (d607d856afc744b1e6bc42cdb9b67b6c4e7e4876).
This also upgrades to libuv.

There are a few modifications to both which will hopefully be upstreamed.
Entirely rewrite our Cocoa/node event loop integration.

Manually run the helper thread instead of using a CFFileDescriptor.  This seems
to avoid some un-understood unreliability and allows the operation to be a bit
cleaner and for the synthentic event to come from the helper thread.
Additionally this changes the general approach of how when integrate with libuv,
which removes a lot of the hacks needed to non-block run the uv event loop in
hopes of getting the kqueue state up to date.
Restructure menu initialize.
There is a race/crash that I haven't managed to understand, involving when the
finishLaunching is called (related to the menu bar) and when a NSWindow is
created.  For example if the JS code runs first and creates a window, everything
is fine.  If finishLaunching is called and later a NSWindow is created we seem
to have a problem with finding the target for the menu items.  I will try to
track this down more properly, for now spin the event loop once to allow any
code to create windows.  If you create the first window on a timer you will
still see a crash, however.
Improve menu hacks, trading one for another.
Instead of pumping the run loop once (which just causes the JS code to run and
create any initial windows), forward on unknown messages from NSWindow to NSApp.
I am not sure why they are being delieved to our WrappedNSWindow instead of the
NSApp anyway.  This is a better solution for the time being though, it means
if you create a window after the first event loop run (based on action or a
timer, etc), the menu items will still work (and apple-q) where we previously
would crash.
Update to new node deps (now hosted on google code).
Fix the menu crashes properly (finally).
In the end it was a use after free (autorelease when setDelegate
doesn't retain) of the NSWindow delegate, which is generally in
our situation unused, except for when the menu action tries to
traverse through the responder chain and dispatches the action
to the NSWindow delegate.  The previous hack of forwarding on
the messages directly to NSApp just avoiding the responder chain
traversal going to the NSWindow delegate.  We don't actually use
the delegate so just leave it nil for now.  In the future if we
do need to use it again, it should of course not be autoreleased.
Cleanup dummy timer constant.
- Correct comment, 11.5 days not 115.
- Some quick experimentation was showing that there is some limit
  somewhere at around 16 days, so I am being on the safe side and
  staying under it, instead of going higher.  It doesn't matter if
  the timer fires anyway.
- Additionally update the the Window timer hack to be the same.
Set the kDummyTimerMs type to const.
I am getting old and forgetting my proper C++.
Try to avoid the whole NSPersistentUIManager system.
When we create a NSWindow (on 10.7+) call setRestorable:NO.
Add a WeakCallback to NSEvent so it is released.
We retain the event when it is created, and release it in the weak callback.
Additionally add a HandleScope to processEvent, since we don't have an implicit
one like when we are called from JavaScript.  Otherwise our handles will be
created in main's HandleScope and never lose that reference.