[pedump] Fix assertion error

[pedump] Fix assertion error

We would previously observe the following crash:

```
ludovic-laptop :: ~/Xamarin/mono ‹16c07b5› » (cd tools/pedump && MONO_PATH=../../mcs/class/lib/net_4_x lldb -- ./pedump --verify metadata,code ../.././mono/tests/xdomain-threads.exe)
(lldb) target create "./pedump"
Current executable set to './pedump' (x86_64).
(lldb) settings set -- target.run-args  "--verify" "metadata,code" "../.././mono/tests/xdomain-threads.exe"
(lldb) r
Process 14407 launched: './pedump' (x86_64)
mono_os_mutex_lock: pthread_mutex_lock failed with "Invalid argument" (22)
Process 14407 stopped
* thread #1: tid = 0x27c9715, 0x00007fff93cfcf06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff93cfcf06 libsystem_kernel.dylib`__pthread_kill + 10
	libsystem_kernel.dylib`__pthread_kill:
	->  0x7fff93cfcf06 <+10>: jae    0x7fff93cfcf10            ; <+20>
	    0x7fff93cfcf08 <+12>: movq   %rax, %rdi
        0x7fff93cfcf0b <+15>: jmp    0x7fff93cf77cd            ; cerror_nocancel
	    0x7fff93cfcf10 <+20>: retq
(lldb) bt
* thread #1: tid = 0x27c9715, 0x00007fff93cfcf06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff93cfcf06 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff8b9b74ec libsystem_pthread.dylib`pthread_kill + 90
	frame #2: 0x00007fff908d56e7 libsystem_c.dylib`abort + 129
	frame #3: 0x000000010022da6a pedump`monoeg_log_default_handler(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, message="mono_os_mutex_lock: pthread_mutex_lock failed with \"Invalid argument\" (22)", unused_data=0x0000000000000000) + 202 at goutput.c:231
	frame #4: 0x000000010022d98d pedump`monoeg_g_logv(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, format="%s: pthread_mutex_lock failed with \"%s\" (%d)", args=0x00007fff5fbff4a0) + 109 at goutput.c:111
	frame #5: 0x000000010022dbd9 pedump`monoeg_g_log(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, format="%s: pthread_mutex_lock failed with \"%s\" (%d)") + 361 at goutput.c:121
	frame #6: 0x000000010022301e pedump`mono_os_mutex_lock(mutex=0x00000001002ec630) + 110 at mono-os-mutex.h:98
	frame #7: 0x0000000100223a66 pedump`mono_w32handle_new(type=MONO_W32HANDLE_PROCESS, handle_specific=0x00007fff5fbff540) + 246 at w32handle.c:440
	frame #8: 0x00000001001ef8bb pedump`_wapi_processes_init + 123 at processes.c:1149
	frame #9: 0x00000001001fbcc3 pedump`wapi_init + 19 at wapi.c:23
	frame #10: 0x0000000100116486 pedump`mono_init_internal(filename="pedump", exe_filename=0x0000000000000000, runtime_version="v4.0.30319") + 102 at domain.c:528
	frame #11: 0x0000000100117124 pedump`mono_init_version(domain_name="pedump", version="v4.0.30319") + 36 at domain.c:868
	frame #12: 0x0000000100001496 pedump`verify_image_file(fname="../.././mono/tests/xdomain-threads.exe") + 678 at pedump.c:466
	frame #13: 0x0000000100000f87 pedump`main(argc=4, argv=0x00007fff5fbff9a0) + 1095 at pedump.c:708
	frame #14: 0x00007fff93e655ad libdyld.dylib`start + 1
```

That would be because the w32handle wouldn't be initialized before calling into `wapi_init` which allocates w32handle.