TestDateParse fail due to ParseDate()

[kcwu]

Fix TestDateParse fail due to ParseDate().
"21 Mar 2006" will be translated as text with Chinese characters on Chinese version windows.
Inside wxStrchr() it will trigger assertion fail because it try to convert non-ascii character to char.

This is because

wxStrchr(const char *s, const wxUniChar& c)

will call

wxCRT_StrchrA()

This patch use

wxStrchr(const wchar_t *s, const wxUniChar& c)

instead.

The other possible fix is change

wxStrchr(const char *s, const wxUniChar& c)

to call

wxCRT_StrchrW()

[vadz]

Thanks for reporting the bug, using wxCRT_StrchrW() for a non-wide string wouldn't work (unless we convert it to wide char first which would be inefficient) but I wonder if wxStrchr(const char *, wxUniChar) shouldn't return false if the character is not ASCII -- after all, it has no chance of finding it in this case.

Vaclav, what do you think about doing this in wxStrchr() itself? It seems that this would make its different overloads more consistent. OTOH it may be argued that searching for a wide char in a narrow string doesn't make sense in the first place in which case this patch should be just applied.

[vaclavslavik]

To be exact, it has no chance of finding the character if it is not convertible as single character to current locale's charset. For example: any ISO-8859-2 character can be found in char* under a locale using ISO-8859-2, not only the ASCII subset of them.

But yes, I do agree that wxStrchr(const char*, wxUniChar) should return false if the wxUniChar cannot be expressed as a char.

[VZ]

(In [62738]) Allow calling wxStrchr() with a narrow string and wide character.

Calls to wxStrchr(char-string, wide-char) would previously fail if wide
character couldn't be converted to a single character in the current locale
encoding. Change it to simply return NULL in this case as it's a safe and
useful generalization: a narrow string will never contain a wide character not
representable in the current locale.

Add wxUniChar::GetAsChar() to help with implementing this.

Closes #11487.