Consider making Bytes a fingertree too

[istathar]

I was talking with @justinlynn and mentioned that Core.Text.Bytes is not, in fact, anything to do with text handling, but rather is just there mostly for historical reasons dating back to when this project was a single unbeliever package.

I remarked that "it had to be in core-text because it was at the base of the dependency tree".

Thinking about that a bit I realized it is nothing of the sort. The Rope type is depended on by everything, but Bytes is just a convenience wrapper. And thinking about it some more, a much better name for it would be Core.Data.Bytes and with that name (by our conventions, at least for the main packages) it might be better in core-data. So I'm proposing to move it there. It could stay in core-text but that would imply that the convenience import Core.Data wouldn't bring it in, and that would be silly.

This would be a 0.4 bump for both packages because of instances moving around, but I can do a point release in 0.3 to mark Core.Text.Bytes deprecated.

The reason I was thinking about this is that the one thing that Core.Text.Bytes's Bytes doesn't do is easy appending, the way that Core.Text.Rope's finger-tree based Rope does. I was thinking about that because if I'm going to port (say) http-streams to become core-webclient{,-streams} then it needs to do LOTS of building ByteStrings (which that library does via Builders, which is tiresome, and a lot of the reason Rope came to be

newtype Rope = Rope (FingerTree Width ShortText)

So maybe instead of

newtype Bytes = StrictBytes (B.ByteString)

Bytes should be

newtype Bytes = Bytes (FingerTree Width ShortByteString)

This would really be a 0.4 bump for both packages because the type of unBytes would have changed, but, well, all the functions like that are marked "internal" for a reason.

[istathar]

Actually core-data's Core.Data could re-export core-text's Core.Data.Bytes just fine. It might be better to leave it in there, mostly because then the two fingertree based types are all in the same package.