Adust GetVersionString() GetBuildInfoString() signatures and move them to OrtApi

[yuslepukhin]

Description

This PR partially reverts changes introduced in #15643

We make two API return std::string always in UTF-8.

We also move the entry points from OrtApiBase to OrtApi to make them versioned.

Motivation and Context

GetVersionString always returns x.y.z numbers that are not subject to internationalization.
GetBuildInfoString can hold international chars, but UTF-8 should be fine to contain those.
We prefix them with u8"" in case the compiler default charset is not UTF-8.
Furthermore, creating platform dependent APIs is discouraged.
ORTCHAR_T is platform dependent and was created for paths only.
On non-unix platforms would still produce std::string that can only contain UTF-8

The API was introduced after the latest release, and can still be adjusted.

[RyanUnderhill]

This needs to be moved into the C API too, as there is no way to detect if it exists. Anyone using a mismatched onnxruntime will just crash.

[snnn]

The APIs are not fully implemented yet. They may not work properly with our release packages.

[snnn]

ORTCHAR_T is platform dependent and was created for paths only.

I created the macro. But I do not think so. The idea behind of it is: All Windows APIs only use wide chars, we should do the same. Now when we see a std::string in our code, it's hard to tell whether the string is encoded with UTF-8 or a Windows code page. And only we have the confusion. Most Windows applications do not use UTF-8. Because of the confusion, we have a number of such mis-encoding issues reported in GitHub issues. For example, now you change the "GetVersionString" function to return a UTF-8 string, but how many people know they cannot pass the returned value to printf/std::cout if the string contains non-ASCII chars? I suggest adding a comment explicitly saying this function could only return ASCII characters. But, remember, the letter A in ASCII means American. We do not build software only for Americans. So in general we should not use this word.

[snnn]

For example, here you pass a std::string directly to printf, it works only if the std::string only contains ASCII chars. But most people are not aware of that.

[yuslepukhin]

We define all strings as UTF-8 internally, except Windows paths. Version string will always be ASCII.

[yuslepukhin]

ORTCHAR_T is platform dependent and was created for paths only.

I created the macro. But I do not think so. The idea behind of it is: All Windows APIs only use wide chars, we should do the same. Now when we see a std::string in our code, it's hard to tell whether the string is encoded with UTF-8 or a Windows code page. And only we have the confusion. Most Windows applications do not use UTF-8. Because of the confusion, we have a number of such mis-encoding issues reported in GitHub issues. For example, now you change the "GetVersionString" function to return a UTF-8 string, but how many people know they cannot pass the returned value to printf/std::cout if the string contains non-ASCII chars? I suggest adding a comment explicitly saying this function could only return ASCII characters. But, remember, the letter A in ASCII means American. We do not build software only for Americans. So in general we should not use this word.

I agree. that's why we use UTF-8. We define this as returning a version string x.y.z where there are all numbers. It would not help if those would be in Russian especially in support cases. But last time I checked, Arabic numerals are the same in the languages known to me.

It does not help using ORTTCHAR. UTF-8 is the same on all platforms including Windows. Are you saying that Linux std::cout would display UTF-8 properly? That's what is implied by the current definition.

This appears to clarify it. The problem is not in UTF-8 or std::cout, but in Windows console.

This clarifies it further

Bottom line, we do not want warp the API because of the issues with the OS. But we can document it.

[RyanUnderhill]

Oops, I wasn't clear when I mentioned it earlier. The 'GetVersionString' function should stay, it just needs to revert to the original signature:

The structure should look like it does here, before the breaking change:

https://github.com/microsoft/onnxruntime/blob/ebaafac3f5a1e318488a1636686bb9bb911d2db8/include/onnxruntime/core/session/onnxruntime_c_api.h#LL629C1-L629C1

struct OrtApiBase {
  /** \brief Get a pointer to the requested version of the ::OrtApi
   *
   * \param[in] version Must be ::ORT_API_VERSION
   * \return The ::OrtApi for the version requested, nullptr will be returned if this version is unsupported, for example when using a runtime
   *   older than the version created with this header file.
   */
  const OrtApi*(ORT_API_CALL* GetApi)(uint32_t version)NO_EXCEPTION;
  const char*(ORT_API_CALL* GetVersionString)(void)NO_EXCEPTION;  ///< Returns a null terminated string of the version of the Onnxruntime library (eg: "1.8.1")
};

[snnn]

For example, if you look the signature of wfopen, even the second parameter could only contain ASCII characters, the type is still a wide-character string. Because it is more consistent. I suggest we follow the same pattern.