Return relative paths with forward slashes on Windows

[salkinium]

On Windows lbuild hands modules relative paths with backslashes, which then land in generated SConstruct/CMake/Python files as lovely escape sequences: generated\nanopb has a newline in it and generated\xpcc is a syntax error, lol. modm currently works around this with a common_posix() helper in about a dozen places (modm-io/modm#1389), but this really should be fixed at the source.

So relative paths now use / on every host. Absolute paths stay native, since modules use them for file system access. Nothing changes on Linux and macOS.

• env.relcwdoutpath(), env.relative_outpath() and env.generated_local_files() return forward slashes.
• BuildLogOperation.filename too, which also covers the collector scope filename and the operation_metadata keys.
• Relative PathOption and PathCollector values too, so ..\..\build in a project.xml comes back as ../../build. Absolute values are left alone.
• Build log XML is written with forward slashes, so it is the same on every host. Logs with backslashes from older versions are still read correctly and lbuild clean works in both directions.
• Unit tests run the Windows path functions via ntpath on every host, so they actually test something on Linux.
• Tested with the Windows Python 3.11 in Wine against modm with common_posix() disabled: Nanopb, XPCC, CMake and CompilationDB examples fail to build with 1.22.0 and build with this.
• Also fine together with the unmodified modm workaround, the generated build files are identical.
• Version increased to 1.23.0, so that modm can require it and drop the workaround.

Heads-up for other repositories: if a module splits these paths on os.sep or compares them with os.path.join() output, that breaks on Windows now.

Missing: Not tested on a real Windows, only in Wine. The test suite also only runs on Linux in CI, a few of the older tests are not Windows-clean anyways.