Base64 optional padding tests

[fonsp]

The pad character = is required in base64 encoding, but not in decoding. Padding characters are not needed to correctly decode: https://en.wikipedia.org/wiki/Base64#Output_padding

This PR makes it possible to decode base64-encoded strings/streams without padding 🎉, matching the behaviour in V8 and in the browser (in data urls).

(The official spec for Base64 states that padding is required for base64-encoding, but it does not specify a requirement for decoding.)

[vtjnash]

SGTM. In fact, it appears the standard is emphatic about this padding being optional:

In some environments, the alteration is critical and therefore
   decoders MAY chose to reject an encoding if the pad bits have not
   been set to zero.

[fonsp]

Thanks! I believe that sentence is about pad bits, not the padding character =. For example, base64-encoding the single-byte input 0b11111111 becomes

First     Second    Third    Fourth
   /
111111    11xxxx    yyyyyy   yyyyyy       

Here, x refers to pad bits, y to pad characters. With the default encoding, x is 0, and yyyyyy is the = character, giving /w==.

The first character should always be /, but the second character depends on the choice of padding bits (x). The spec states that during encoding, these should be zero (thus giving 110000, which is w), but during decoding, pad bits should be ignored, so any character between 110000 and 111111 should lead to the same result.

Although this was not part of my PR (and it was already implemented correctly), I added some tests about decoding pad bits here: https://github.com/JuliaLang/julia/pull/44503/files#diff-4fcfc93f2fff4705dceba7d3c1ef7d3aa0c7653ccff897ddc7ab664c4f9b1e37R102 , and cross-checked these with Chrome's implementation.

[DilumAluthge]

This seems like a bug fix. Can we backport it to 1.6, 1.7, and 1.8?

[vtjnash]

It is a new feature mostly