With Boost 1.78 (installed on my system), I get a compiler error:

```
./fs.h: In function ‘fs::path fs::operator+(fs::path, fs::path)’:
./fs.h:91:8: error: no match for ‘operator+=’ (operand types are ‘fs::path’ and ‘std::remove_reference<fs::path&>::type’ {aka ‘fs::path’})
   91 |     p1 += std::move(p2);
      |     ~~~^~~~~~~~~~~~~~~~
```

It appears that in Boost 1.78, `operator+=` became a template function, and our `path` class which subclasses `boost::filesystem::path::path` no longer has an `operator+=` which will work with it.

I also opened an issue with boost: https://github.com/boostorg/filesystem/issues/223
{
    p1 += std::move(p2);
    return p1;
}
static inline void copy_file(const path& from, const path& to, copy_option options)
{
    boost::filesystem::copy_file(from, to, options);
}
/**
 * Convert path object to byte string. On POSIX, paths natively are byte
 * strings, so this is trivial. On Windows, paths natively are Unicode, so an
 * encoding step is necessary. The inverse of \ref PathToString is \ref
 * PathFromString. The strings returned and parsed by these functions can be
 * used to call POSIX APIs, and for roundtrip conversion, logging, and
 * debugging.
 *
 * Because \ref PathToString and \ref PathFromString functions don't specify an
 * encoding, they are meant to be used internally, not externally. They are not
 * appropriate to use in applications requiring UTF-8, where
 * fs::path::u8string() and fs::u8path() methods should be used instead. Other
 * applications could require still different encodings. For example, JSON, XML,
 * or URI applications might prefer to use higher level escapes (\uXXXX or
 * &XXXX; or %XX) instead of multibyte encoding. Rust, Python, Java applications
 * may require encoding paths with their respective UTF-8 derivatives WTF-8,
 * PEP-383, and CESU-8 (see https:en.wikipedia.org/wiki/UTF-8#Derivatives).
 */
static inline std::string PathToString(const path& path)