move std.{ascii, base64, utf} to a new encoding package

[LaTeigne via Digitalmars-d]

On Monday, 8 August 2016 at 19:42:50 UTC, Seb wrote:
> Hi all,
>
> today Johannes and I had a short discussion on Github about 
> std.base64. I think his post is a good summary of the status 
> quo:
>
>> base64 shouldn't be a top level module though, moving it to a 
>> new package std.encoding may be a good idea. std.base64 is 
>> just quite old and when it was written we didn't use 
>> subpackages in phobos yet. std.utf and std.ascii are also 
>> encodings and could be moved to std.encoding as well, AFAICS. 
>> And we also have a std.encoding module which should be part of 
>> the same package.
>
> That being said I know that such housekeeping isn't liked a 
> lot, but with `public import` we can very easily mitigate 
> breakage and allow a long deprecation period.
> What's your opinion on this? Any major objections?
>
> Cheers,
>
> Seb
>
> [1] 
> https://github.com/dlang/phobos/pull/4720#issuecomment-238348553

They're all related to encoding but they don't have a proper 
common interface like std.digest or std.experimental.allocators

I think it would be justified for something like

std.encoding.variable_length_quantity
std.encoding.z85
std.encoding.base64
std.encoding.base32
std.encoding.base16
etc...

with an uniform API (decode, encode, + specialized helpers)

I you do it as the modules are now it's gonna look like the 
content of a girl bag because of no uniform API.

In short I'm against unless a serious work is done on the API, 
otherwise it's just a crappy useless refactoring.