Remove deprecated methods and modules in the next major version.

[phadej]

No description provided.

[Bodigrim]

• Modules Data.ByteString.Lazy.Builder, Data.ByteString.Lazy.Builder.ASCII, Data.ByteString.Lazy.Builder.Extras are deprecated since 0.10.2.0, released in 2012.
• Data.ByteString.Lazy.Builder.ASCII.byteStringHexFixed and Data.ByteString.Lazy.Builder.ASCII.lazyByteStringHexFixed are marked as deprecated only in master, but their module itself is deprecated since 0.10.2.0, released in 2012.
• Data.ByteString.hPutStrLn, Data.ByteString.putStrLn, Data.ByteString.Lazy.putStrLn are deprecated since 0.10.0.0, released in 2012.
• Data.ByteString.breakByte is deprecated since 0.10.6.0, released in 2015.
• Data.ByteString.Internal.inlinePerformIO is deprecated since its first exposure to external users (in 0.10.10.0).
• Data.ByteString.Builder.Prim.Internal.boudedPrim is deprecated since 0.10.12.0, released in 2020.

[Bodigrim]

I think we should grab an opportunity to clean up all these functions and modules in the upcoming 0.11.0.0 release, otherwise they'll linger around for another decade.

The only function, which was deprecated only recently and not ages ago, is boudedPrim, but I believe it's acceptable to change the interface of an internal module in a major release without further ado.

Opinions? @sjakobi @bgamari @hsyl20

[sjakobi]

My preference would be not to remove boudedPrim yet since we've only deprecated it in August. In general, I think we should aim for deprecation periods that are not much shorter than 1 year. Even when bytestring is moving quickly in some parts, it's nice to offer stability in the rest.

I believe it's acceptable to change the interface of an internal module in a major release without further ado.

In the case of bytestring I'm not so sure about this yet. I think it would be good to make progress on #253 and clarify the stability guarantees of the internal modules first.

No objections to the other removals.

[Bodigrim]

@sjakobi OK, let's err on the side of caution here.