Why deprecate EncodingError?

[ag-eitilt]

In #112, the decision was made to deprecate some of the error handling for encoding functions, on the basis that none of the library functions actually use them. That is indeed true, but only since it only provides UTF encoding functions -- that capability can still be helpful for people building on the library for compatibility encodings. The EncodingError constructor, especially, seems like it might be nice to keep around since it, unlike the OnEncodingErrortype, isn't something that can be reconstructed from the outside (for example, I'm not actually using the latter since the encoding I'm working with -- SHIFT JIS -- needs multiple bytes per character). It's nothing critical since I can just make my own replacements or otherwise work around the deprecations, but it just seems a bit closed-garden.

EDIT: I should say, I'm not even sure I want to use DecodeError due to the double-width characters, but the question still stands for the preponderance of historic single-byte encodings.

[Lysxia]

There are also requests to add non-Unicode encoders in text (#324, #252), that would make something like EncodingError useful again.

At the same time I'm not a fan of putting both encoding and decoding errors as two separate constructors in the same type. And the Maybe doesn't make sense for encoding because "ran out of input" is not an error that should ever happen for a valid Text.

So we can take the deprecation as an opportunity to rethink that error handling, especially if we'd like the same mechanisms to be used by external encoders.