Windows addon loaders are unreachable and swallow load errors

[kraenhansen]

Grouping the FIXME/HACK in CxxNodeApiHostModule.hpp with the four TODOs in AddonLoaders.hpp. Both halves of the Windows story are incomplete, and the first makes the second unobservable.

The loader policy is hardcoded to POSIX

react-native-node-api/packages/host/cpp/CxxNodeApiHostModule.hpp

Lines 45 to 46 in 29a527d

	using LoaderPolicy = PosixLoader; // FIXME: HACK: This is temporary workaround
	// for my lazyness (work on iOS and Android)

Win32Loader and WinRTLoader exist in AddonLoaders.hpp and are compiled behind #if defined(_WIN32), but nothing ever selects them — LoaderPolicy is unconditionally PosixLoader. The alias should be chosen by platform (_WIN32 → Win32Loader, with WinRT distinguished by the appropriate API-family macro, POSIX otherwise), which is a compile-time #if rather than a design question.

The Windows loaders discard the reason for every failure

All four failure paths detect the error and then do nothing with it:

react-native-node-api/packages/host/cpp/AddonLoaders.hpp

Lines 52 to 57 in 29a527d

	Module result = LoadLibrary(filePath);
	if (NULL == result) {
	// TODO: Handle the error case... call GetLastError() that gives us error
	// code as DWORD
	}
	return result;

react-native-node-api/packages/host/cpp/AddonLoaders.hpp

Lines 63 to 68 in 29a527d

	Symbol result = GetProcAddress(library, name);
	if (NULL == result) {
	// TODO: Handle the error case... call GetLastError() that gives us error
	// code as DWORD
	}
	return result;

react-native-node-api/packages/host/cpp/AddonLoaders.hpp

Lines 84 to 89 in 29a527d

	Module result = LoadPackagedLibrary(filePath);
	if (NULL == result) {
	// TODO: Handle the error case... call GetLastError() that gives us error
	// code as DWORD
	}
	return result;

react-native-node-api/packages/host/cpp/AddonLoaders.hpp

Lines 95 to 100 in 29a527d

	Symbol result = GetProcAddress(library, name);
	if (NULL == result) {
	// TODO: Handle the error case... call GetLastError() that gives us error
	// code as DWORD
	}
	return result;

LoadLibrary/LoadPackagedLibrary/GetProcAddress all return null and leave the reason in GetLastError(). Returning null without capturing it means the caller in CxxNodeApiHostModule.cpp can only report "Failed to load library" — the distinction between "file not found", "a transitive dependency is missing" and "wrong architecture" is lost, and those are precisely the three things a developer needs to tell apart. PosixLoader has the same shape of gap but at least has dlerror() available; the commented-out NSLog there suggests it was once wired up.

Suggested minimum: format the DWORD via FormatMessageA and route it through log_error/log_debug from Logger.hpp, matching how the POSIX path should report dlerror().

Both were listed in the original permalinks on #30. Relevant to #305 (Windows test app on CI) — without a Windows test app these paths stay unexercised whichever way they are fixed.