Remove std::string and std::filesystem::path types from the libloot api

[putertubby]

I'm working on a simple C++/CLI wrapper for libloot but end up in trouble because the std::string and std::filesystem::path type definitions are different in the wrapper compared to the definitions used when the libloot binaries were built.

Essentially I end up in the situation decribed here: https://stackoverflow.com/questions/35464520/calling-a-native-c-dll-with-stdstring-argument-from-c-cli

I could potentially solve this by making sure I use exactly the same compiler and development environment for my wrapper as was used when building the libloot binaries. However, that solution would be brittle since future libloot releases might use different development environments and thus crash the wrapper.

For this reason I propose to remove compiler-dependent types from the api.

[Ortham]

Though it seems self-contradictory (or at least unclear) in places, Microsoft says that it maintains stability across minor versions of MSVC (so MSVC 2015, 2017 and 2019 are all compatible), so what toolset are you using that gives you incompatibilities?

This runs deeper than just not using std::string and std::filesystem::path: the C++ ABI is unstable and the only really portable solution I know of is to only expose a C API/ABI. The loot-api-c repository holds an old C API wrapper, but it wasn't worth the maintenance cost because it was only used as one half of the code to expose a Python API, and pybind11 let me do the whole thing much more easily. I have toyed with the idea of updating the loot-api-c repository, but haven't ever had enough of a justification for it.

[putertubby]

Thanks for the link. I'm using Visual Studio 2017 (v141) so in theory I shouldn't have any incompatibility issues. I'll have another look at the problem and if it persists look into loot-api-c.