Some really big issues with the GLFW and Vulkan bindings
Hi NimGL maintainers! Thanks for all of the hard work that's been poured into these bindings, especially by you @lmariscal ! They're really a huge boon to the game development community!

Having said that, I've come across a number of pretty big issues in the Vulkan and GLFW bindings that I think need addressing.

The bindings aren't correct in a number of places - for instance dispatchable handles (VkInstance, VkPhysicalDevice, etc...) should be pointers to opaque types, not sixty-four bit signed integers. You can see this if you take a look at `vulkan_core.h` in the `VK_DEFINE_HANDLE` macro or if you check out the vulkan specification it states it there too.

For non-dispatchable handles, sixty-four bit unsigned integers should be the type when the platform isn't in this list:
```#if defined(__LP64__) || defined(_WIN64) || (defined(__x86_64__) && !defined(__ILP32__) ) || defined(_M_X64) || defined(__ia64) || defined (_M_IA64) || defined(__aarch64__) || defined(__powerpc64__)```

And then depending on the compiler and C++ language level being compiled against, `VK_NULL_HANDLE`'s definition varies...

The `passC` pragmas for `vcc` in `glfw.nim` are wrong - they use `-D` which is going to be ignored by `vcc` because `vcc` is really just `cl.exe` and `cl.exe` takes in compiler defines with `/D`.

Right now if you compile for vcc with the cpp backend, you won't even be able to get a simple example working on Nim 1.4.8 because the generated C++ is bad because the bindings are incorrect. 

There are also compiler defines that are missing which are expected by GLFW according to the docs. https://www.glfw.org/docs/3.3/vulkan_guide.html#vulkan_include for instance...

I think there are a lot of issues like this spread throughout the codebase. I'd be happy to help work with you guys to identify them - but if so I think it'd be more productive if we set up a channel to communicate with somewhere instead of github issues. Happy to talk on discord or wherever... If you'd prefer I can file separate Github issues for all the issues I encounter, but to be honest I can't spend all my time trying to figure out all the places the bindings are wrong, so I would most likely just file issues for the things I'm aware of, and then continue working on my own bindings, because these are unusable for me.

One idea I just had was - I could fix the bindings themselves and then leave fixing the generator up to you guys. That or I could just give you guys a copy of my bindings once they're complete and we could do it that way too. I'm writing mine by hand as I encounter identifiers that are unresolved - but eventually I imagine they'll reach completion - it just might be around the same time my game's renderer is finished, and even then I can't promise they'll be complete :P Anywho, lmk what yall think!

Please ping me on discord (@Gumber) or reply here if you'd like to chat! Happy to do so whenever :D Hope you all have a great weekend!
