Deprecation of System.OsString in `1.4.200.1`

At the risk that this will turn into a rant...

When migrating form GHC 9.8.1 to 9.8.2 I'm confronted with:

```
Deprecated: Use System.OsString from os-string >= 2.0.0 package instead. This module will be removed in filepath >= 1.5.
```

So yeah, moving stuff into separate packages can make sense. But wait, why doesn't `filepath` just, re-expose that module from `os-string`? Probably because they wanted to add the deprecation message? But this means that we will end up with clashing module names, uhhh... whatever, do I really care? Just use `PackageImports` and be done with it... oh, wait, WHAAAAAT, `filepath` does not even depend on `os-path`???

So what exactly am I going to do with this deprecation warning, except for ignoring it?

And how useful is a deprecation warning that provides a "course of action" that will result in compilation errors in all but the most exotic cases. How useful is a deprecation warning that you can only ignore, where there is no sensible action to take?

So what I'm going to do is add a `OPTIONS_GHC` to every affected module, to ignore the warning. This is mostly harmless, except for that it maps any other deprecation warnings, deprecation warnings that may provide actual value... and then, down the road, when I transition to a newer version of GHC / filepath I'll have to remember to remove those
`OPTIONS_GHC`s again...

Sounds like a lot of wasted effort to me... for what?

Read the issue discussion around System.OsString, filepath, os-string, and the proposed OPTIONS_GHC workaround first. Determine whether the project has settled on a deprecation or compatibility direction; done would require an agreed course of action, since the issue currently describes a design problem rather than a specific file or test change.

Written by the indexing model from the issue text.