Fix SQLWCHAR conversion paths on Linux (draft)

[fdcastel]

Summary

Draft reference implementation against the widechar test suite in #290. Fixes the MainUnicode.cpp Linux branches that assumed sizeof(SQLWCHAR) == sizeof(wchar_t).

Note: this branch is layered on top of #290, so the diff here includes both the tests (from #290) and the Unicode fix. Review the commits individually, or wait for #290 to merge and this will rebase cleanly to show only the Unicode fix.

What this PR does

• ConvertingString destructor (output path, used by SQLGetDiagRecW / SQLErrorW): Linux branch now does a byte-level widening loop (SQLCHAR → SQLWCHAR) instead of mbstowcs((wchar_t*)...) — the latter wrote UTF-32 into a UTF-16 buffer on Linux, truncating HY000 to H and smashing the stack on tight output buffers.
• convUnicodeToString (input path, used by SQLExecDirectW / SQLPrepareW): Linux branch does the inverse byte-narrowing loop instead of wcstombs, and uses a local sqlwcharLen helper instead of wcslen((wchar_t*)...).
• lengthString = length / sizeof(SQLWCHAR): correct character count in the length-specified ctor.
• NUL-terminate in SQLWCHAR units. In convUnicodeToString, *ptEndWC = L'\0' through a wchar_t* was a genuine 4-byte write into a 2-byte SQLWCHAR slot on Linux and is the real fix. The sibling *(LPWSTR)... in the destructor is a 2-byte narrowing store — not an overrun, per @irodushka in Add ASAN and Valgrind integration for CI test suite #289 (discussion_r3109004999) — so the replacement there is a style simplification, not a fix.

Mirrors unixODBC's own ansi_to_unicode_copy / unicode_to_ansi_copy approach.

Scope / Out of scope

• Does not close Tier 1b entirely — the connection->MbsToWcs / WcsToMbs branch and non-ASCII (iconv) handling remain open.
• This PR also removes the Linux-only GTEST_SKIP guards added in Add widechar ODBC call tests (driving Unicode fix) #290, so the test suite runs on every platform.

Context

Per @irodushka's plan in #289 comment 4279111183. Opened as draft so either:
(a) @irodushka approves and it lands,
(b) @irodushka pushes his own implementation on top, or
(c) @irodushka closes it and opens his own, using #290's tests as the acceptance criteria.

Test plan

• CI run green on all platforms including ASAN strict
• Windows: widechar tests from Add widechar ODBC call tests (driving Unicode fix) #290 still pass
• Linux: widechar tests from Add widechar ODBC call tests (driving Unicode fix) #290 now pass (skips removed)
• Valgrind: no new leaks

[irodushka]

@fdcastel

NUL-terminate in SQLWCHAR units (no LPWSTR 4-byte write past the end on Linux).

Please read again this explanation #289 (comment)
I tried to explain that the changes you made were not a bug fix, but an optional code styling. That the C/C++ code like

int64_t x = 0;
int32_t y = x;

or

int64_t x = 0;
int32_t y;
int32_t *py = &y;
*py = x;

contains no bug.
Well, maybe you think I'm wrong? Let's discuss it.

[irodushka]

ok!

[fdcastel]

@irodushka Agreed on the destructor case — *(LPWSTR)ptr = L'\0' is a 2-byte narrowing store on unixODBC (LPWSTR == SQLWCHAR* == unsigned short*), not an overrun. Already corrected in 0d9bce9: the overrun comment was dropped and unicodeString[len] = 0; was kept only as the style simplification you endorsed. The PR description still overclaimed it as a bug fix — fixing that now.

One distinction worth separating on the sibling case in convUnicodeToString: pre-PR code declared wchar_t *ptEndWC and did *ptEndWC = L'\0';. There the pointee type is already wchar_t, so no narrowing happens — the store is sizeof(wchar_t) == 4 bytes on Linux into a 2-byte SQLWCHAR slot. That one is a genuine 4-byte overrun and the fix stays. Let me know if you read that one differently.

[fdcastel]

PR description updated to reflect the distinction.

[irodushka]

Suggested change

	ptEndWC = (wchar_t*)&wcString[length];
	ptEndWC = wcString + length;

[irodushka]

Suggested change

	wchar_t saveWC;
	SQLWCHAR saveWC;

[irodushka]

Suggested change

	SQLWCHAR *ptEndWC = NULL;

[irodushka]

Yep. This place

			ptEndWC = (wchar_t*)&wcString[length];
			saveWC = *ptEndWC;
			*ptEndWC = L'\0';

really looks like overrun. Frankly, two overruns - 1) *ptEndWC = L'\0'; - you've fixed it 2) saveWC = *ptEndWC; - out-of-bound read, not fixed yet)) A read is not so deadly as a write, but it can lead to UB or even crash.

and in the second place, at the end of the function:

		if ( ptEndWC )
			*ptEndWC = saveWC;

this's the third real write overrun)) unfixed)

I think it's easier to rewrite this than to try to fix all those issues...

[fdcastel]