Find a solution for `bytestring` and `text` depending on low-level I/O functionality

The accepted CLC proposal #392 calls for deprecating all `base` modules with stability risk 3 and [GHC merge request !15411](https://gitlab.haskell.org/ghc/ghc/-/merge_requests/15411), which is still pending, implements this. However, carrying out this deprecation would result in `bytestring` and `text` having to depend on `ghc-internal`. They contain a lot of I/O-related code that is similar to code in `ghc-internal`, with the difference that instead of strings it uses byte strings or text, and this code needs access to low-level entities, which should not be provided by `base`.

I already wrote about this problem [in my documentation on stability-risk-3 modules](https://github.com/well-typed/reinstallable-base/blob/main/hackage-uses-of-internals/stability-risk-3/by-purpose.md#untreated-use-explanations), where I recommended to redesign parts of `ghc-internal`, `bytestring`, and `text` such that the latter do not need to depend on `ghc-internal` anymore. My assumption was that such a redesign could happen later, but apparently several people are of the opinion that the deprecation of the above-mentioned modules should not go ahead if it would involve introducing a `ghc-internal` dependency.

As a result, I would like to start a discussion about how to solve the problem with the I/O-related code in `bytestring` and `text`. I particularly invite the maintainers of `bytestring` and `text`, among which to my knowledge are @Bodigrim and @TeofilC, to share their views on this matter. My own opinion is that the I/O functionality that `bytestring` and `text` essentially duplicate should be implemented only in `ghc-internal` but not based on strings but on something more fundamental, so that the string-based I/O operations of `base` as well as the byte-string- and text-based I/O operations of `bytestring` and `text` can be built on top of it.