Builds with allow-newer unnecessarily fail

[josephcsible]

Using cabal with --allow-newer will break the build as of directory 1.3.8.2. The problem is that the os-string flag introduced in #165 defaults to the older way, so it will end up not using os-string even though it will be on the latest version of filepath. For now, I'm working around this by also passing -c 'directory +os-string' to cabal, but that shouldn't be necessary for everyone who ever uses --allow-newer. Any one of these three changes will fix it:

1. Changing that flag to default: True
2. Keep the flag default: False, but invert the meaning of it, like QuickCheck does
3. Get rid of the flag altogether, and use os-string on GHC 9.2+ instead, like Hashable does

[hasufell]

A related problem is that cabal treats boot packages specially, which is a bug: haskell/cabal#9669

Naturally, cabal should try to get a newer filepath and then realise it can only do so when os-string is enabled.

The reason it's off by default is exactly because of the interaction with boot libraries. I'm not sure switching the default won't cause problems for older GHCs.

Getting rid of the flag seems like a bad idea for backwards compatibility.

So I think this needs better evidence on how it behaves across different GHC versions with and without allow-newer, when the build plan requires directory to be compiled from source and when it doesn't.

I'm unable to reason about cabal's behavior in that much detail.