excise Base64 stuff from Base

[StefanKarpinski]

Base64 would be fine in the standard library, but should really not stay in Base.

[stevengj]

The stringmime function (used in ~25 registered packages) will have to be moved, too.

Many of the uses of stringmime in packages seem to be for text data, and can be deprecated to reprmime. The remaining cases (Atom, Escher, IJulia, Images, Interact, Jewel), which require base64 encoding of binary data, can use Base64.stringmime.

[bicycle1885]

I've made a faster base64 encoder with the same interfaces of Base. The performance improvement is more than 10 times and it would be good to move it to the standard library (the code is here: https://gist.github.com/bicycle1885/f3db61e15ba08b291435bb3e2b2b67c5).

I guess the best way to deprecate the current base64 tools is to keep them as is, deprecate them, and create a new module under the stdlib directory, right?

[StefanKarpinski]

Also note that there a a number of different Base64 variants and this only implements one of them. Stranger than baking one particular data encoding into the base language is picking one particular variant of one particular data encoding and baking just that into the base language.

[aviks]

I recently needed a base32{encode|decode} function. Found it hidden inside some other package. Would be good to get them together with base64 somewhere.

[bicycle1885]

I've made a Base32 encoder/decoder in CodecBase.jl, so it is trivial to implement those functions.

[JeffBezanson]

closed by #24361