cubeb __FILENAME__ macro incorrectly uses / to delimit paths on windows

[mutexlox-signal]

Since #581, cubeb_log.h has used the following logic to strip __FILE__ to only include the basename of the file (rather than the whole path):

#define __FILENAME__                                                           \
  (strrchr(__FILE__, '/') ? strrchr(__FILE__, '/') + 1 : __FILE__)

Unfortunately, this is incorrect on Windows, since it uses '\' to delimit paths. In practice, this can lead to logs from, e.g., cubeb_wasapi.cpp being needlessly truncated, like the following, from ringrtc, which uses cubeb-rs:

C:\a\ringrtc-private\ringrtc-private\target\x86_64-pc-windows-msvc\release\build\cubeb-sys-5b33f650b6d0fb14\out\libcubeb\src\cubeb_wasapi.cpp:691:collection: Audio device state changed, id = {0.0.0.00000000}.{[omitted irrelevant uuid]}, state =

Note that a full 125 of the available 256 characters in the log string are taken up by the path.

[mutexlox-signal]

From https://github.com/mozilla/cubeb/blob/master/CMakeLists.txt#L38-L39, it looks like cubeb is on C++17, which contains the standard function https://cppreference.com/cpp/filesystem/path/filename, which should perform this function in a suitably cross-platform way.

However, as filesystem::filename is C++, this would cause problems with C files including cubeb_log.h.

That said, we should be able to work around this by defining a function to wrap it in cubeb_log.cpp.

I'll double-check this and put up a PR.

[mutexlox-signal]

filesystem::path::filename turns out to convert from a char* to a wchar_t* on windows, at least sometimes, so it's not as easy to use here. Nonetheless, #853 is up