ggml-backend : keep paths in native string type when possible

[slaren]

Avoids conversions from std::filesystem::path to non-native std::string to prevent possible issues when converting between different encodings. When unavoidable (e.g. to print a path), checks for exceptions.

Fixes #11198

[gnusupport]

Thanks for fixing this issue.

[MaggotHATE]

This change causes errors with w64devkit on Windows 10 (c++2a):

ggml-backend-reg.cpp:78:32: error: no match for 'operator=' (operand types are 'std::string' {aka 'std::__cxx11::basic_string<char>'} and 'std::u8string' {aka 'std::__cxx11::basic_string<char8_t>'})
   78 |         u8path = path.u8string();
      |                                ^

Reverting this change fixes the issue (even with latest commits).

UPD: I'm not sure how to fix this correctly since

        std::u8string u8path_u8 = path.u8string();
        u8path = std::string(u8path_u8.cbegin(), u8path_u8.cend());

looks rather ugly, even if it works.

[slaren]

path.u8string returns a std::string in C++17, but a std::u8string in C++20. If some parts of your application need C++20 or higher, you can try building only these with C++20 enabled and continue building ggml and llama.cpp with C++17.

[MaggotHATE]

path.u8string returns a std::string in C++17, but a std::u8string in C++20. If some parts of your application need C++20 or higher, you can try building only these with C++20 enabled and continue building ggml and llama.cpp with C++17.

This PR is the only thing that makes llama.cpp incompatible with C++20, shouldn't it be fixed? It seems a bit weird to leave it this way.

[slaren]

I am not sure what's the point since you can just build ggml with the correct flag, and I am not interested in supporting C++20, but if that's something that you care about feel free to open a PR.