Allocate correct number of pointers for events

 - The FFI memory pointer initializer takes a count of the type it's
   allocating, not the number of total bytes
Prevent Daemon exceptions from deadlocking service

 - If any methods that respond to the SCM throw an exception, the
   @@hStopCompletedEvent is never signaled and the service can hang.
   This includes service_pause, service_resume, service_interrogate,
   service_shutdown, service_paramchange, service_netbindadd,
   service_netbindremove, service_netbindenable, service_netbinddisable,
   or service_stop.  Effectively, guard against user-defined classes
   derived from Win32::Daemon misbheaving and hanging the service.
Use CreateThread user param for StartServiceCtrlDispatcher

 - The 4th parameter to the CreateThread function is an LPVOID that
   allows a user parameter to be passed to the newly created thread.
   Instead of using a Ruby closure over Service_Main within the
   ThreadProc (which could be considered a bit dangerous with respect
   go GC), perform a safer operation by passing a native pointer to
   the function.
Prevent Service_Main exceptions from deadlocking service

 - If the code within Service_Main throws an exception or otherwise
   exits prematurely, then the call will never be made to
   SetTheServiceStatus to tell the SCM that the service has successfully
   completed.  Without this notification sent to the SCM,
   StartServiceCtrlDispatcher will never return and the service will
   hang with a status of STOP_PENDING.
 - This exact behavior has been observed within the Ruby 2.0 x64
   environment, where due to unknown reasons, the Service_Main thread
   is prematurely terminated.  In this particular case, as soon as
   Service_Ctrl_ex is called by the SCM, Service_Main appears to die
   immediately.  In observed cases, there is some race condition
   present as the situation is not always reproducible.
Return correct codes from Service_Ctrl_Ex

 - According to the MSDN documentation for the HandlerEx function, it
   should geneally return NO_ERROR, or ERROR_CALL_NOT_IMPLEMENTED:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683241(v=vs.85).aspx
   Presently the return value from the HandlerEx function is whatever
   the return value happens to be from the SetTheServiceStatus function.
   This is technically not correct, and thus the code has been
   updated to reflect this.
Merge pull request #21 from Iristyle/fix-deadlock

Prevent deadlocks from hanging service - closes #20