src: napi-inl: Fix a memory leak bug in AsyncProgressWorkerBase

In `AsyncProgressWorkerBase<DataType>::NonBlockingCall` if the call to
`_tsfn.NonBlockingCall()` doesn't return a `napi_ok`, the ThreadSafeData
object is not deleted by `OnAsyncWorkProgress()`, resulting a memory
leak bug.

Report from ASAN (Address Sanitizer):
```
  Direct leak of 2706523824 byte(s) in 169157739 object(s) allocated:
  # 0 0x7fc83c2dd76d in operator new(unsigned long)
  # 1 0x7fc83b639fc2 in Napi::AsyncProgressWorkerBase<void>::NonBlockingCall(void*)
  # 2 0x7fc83b639fc2 in Napi::AsyncProgressWorker<unsigned char>::SendProgress_()
  # 3 0x7fc83b635cd0 in Napi::AsyncProgressWorker<unsigned char>::ExecutionProgress::Send()
  # 4 0x7fc83b635cd0 in WaitCQEWorker::Execute()
  # 5 0x7fc83b636545 in Napi::AsyncProgressWorker<unsigned char>::Execute()
  # 6 0xb8df59 in node::ThreadPoolWork::ScheduleWork()::'lambda'(uv_work_s*)::_FUN(uv_work_s*)
  # 7 0x1768fb3 in worker /home/iojs/build/ws/out/../deps/uv/src/threadpool.c:122:5
  # 8 0x7fc83ba94b42 in start_thread nptl/./nptl/pthread_create.c:442:8
```

Fix this by deleting the tsd variable if `_tsfn.NonBlockingCall()`
doesn't return a `napi_ok`.

Signed-off-by: Ammar Faizi <ammarfaizi2@gnuweeb.org>

PR-URL: #1264
Reviewed-By: Michael Dawson <midawson@redhat.com
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Kevin Eady <kevin.c.eady@gmail.com>

napi-inl.h

@@ -5889,7 +5889,11 @@ template <typename DataType>
 inline napi_status AsyncProgressWorkerBase<DataType>::NonBlockingCall(
     DataType* data) {
   auto tsd = new AsyncProgressWorkerBase::ThreadSafeData(this, data);
-  return _tsfn.NonBlockingCall(tsd, OnAsyncWorkProgress);
+  auto ret = _tsfn.NonBlockingCall(tsd, OnAsyncWorkProgress);
+  if (ret != napi_ok) {
+    delete tsd;
+  }
+  return ret;
 }
 
 template <typename DataType>