Resolve the runtime module rather than assuming the executable

[bavulapati]

On win32 a prebuilt addon delay-loads bare.dll, and the hook answers with GetModuleHandle(NULL), then looks up bare_module_find on it. That's the executable. Right for bare, wrong for anything that embeds the runtime in a library instead: bare-kit keeps it in bare-kit.dll, which exports all 3433 symbols but never gets consulted, so no addon loads. There's currently no way to embed bare-kit on win32 and load a stock prebuilt addon.

This resolves the runtime module instead of assuming it: use the executable when it exports bare_module_find, otherwise take whichever loaded module does. No name is hardcoded, so it holds for any embedder. PSAPI_VERSION 2 makes EnumProcessModules resolve against kernel32, so no new link dependency - I checked, delayimp.lib alone still links.

Verified both branches on win32-arm64 by compiling the hook into a test exe and asking it what it resolved:

exe exports bare_module_find: no    ->  resolved runtime: ...\bare-kit.dll
exe exports bare_module_find: yes   ->  resolved runtime is the exe: yes

Worth being explicit about the propagation: the hook is compiled into each addon, so this only reaches a host as addons are rebuilt and republished. sodium-native and udx-native as published today still carry the current hook. Until they're refreshed, a bare-kit host on win32 still needs to re-export the runtime symbols itself, which is the workaround this exists to remove (holepunchto/bare-windows#7).

What I haven't done: an end-to-end run of a freshly built addon inside a bare-kit host with no forwarders. Happy to do that if you want it before this lands.