It was broken by CL 22378.
The bug was in the situation when "==" (two padding chars) were at
the end, the reading did not stop after the first '=',
and thus one more char of output was generated.
Add more unit-test for base64 decoding.
Rewrite Base64InputStream to be much more efficient
This was broken in many, many ways but the primary offender was an
object allocation for every 4 bytes of an input stream (imagine what this
did for 900k attachment files).
The new version is completely self-contained, and is optimized for the
most common case of inner loop case of processing 4-bytes-at-a-time.
