Support bytestring-0.10

[edsko]

We were previously explicitly using on BS constructor, which changed in bytestring-0.11. Fortunately, it is not too difficult to avoid this.

On the pattern matching side, instead of

compress (BS sfp slen) = 
    ..
    withForeignPtr sfp $ \sptr ->
      ..

we can do

compress bs =  
    ..
    unsafeUseAsCStringLen bs $ \(sptr, slen) ->
      ..

which does the same thing:

unsafeUseAsCStringLen :: ByteString -> (CStringLen -> IO a) -> IO a
unsafeUseAsCStringLen (BS ps l) action = withForeignPtr ps $ \p -> action (castPtr p, l)

On the construction side, instead of

dfp <- mallocForeignPtrBytes ..
withForeignPtr dfp $ \dptr ->
  ..
    return $ BS dfp ..

we can instead do

dptr <- mallocBytes ..
..
unsafePackMallocCStringLen (dptr, ..)

which then adds the finalizer (which was previously added by
mallocForeignPtrBytes):

unsafePackMallocCStringLen :: CStringLen -> IO ByteString
unsafePackMallocCStringLen (cstr, len) = do
    fp <- newForeignPtr c_free_finalizer (castPtr cstr)
    return $! BS fp len

Supporting bytestring-0.10 makes install plans a lot easier, especially on CI (upgrading bytestring is possible, but bytestring has a lot of dependencies, all of which then need to be updated also). Accordingly, this simplifies the cabal.haskell-ci file.

/cc @FinleyMcIlwaine

[edsko]

@FinleyMcIlwaine I made an independent fork of snappy at https://github.com/edsko/snappy/tree/edsko/bytestring-0.11 , because your fork required bytestring-0.11, which initially confused me (why would such an old and unmaitained package require a new version of bytestring?) until I realized you needed that only to hide the BS constructor to avoid the name clash. I instead renamed the local BS constructor to WrapBS; this appears to be the only change actually required to build it.

I guess I can submit a PR against your fork, or we can drop your fork in favour of mine, I don't mind either way (but GitHub doesn't recognize your fork as being a fork, for some reason..? 🤔 ).