Add base 64 encoding/decoding extensions.

[JakeWharton]

I'm really not sure what to do about the parameter order. flags seem like the most useful and they're present on every overload so I put them first, but it's definitely weird to have offset/length be not first. Thoughts?

Closes #406.

[googlebot]

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

[jaredsburrows]

I have signed the @google CLA(check previous PRs) and I am in the @google organization: https://github.com/jaredsburrows.

[jaredsburrows]

Ideally it would nice to keep parameters in order with the method but flags does seem to be more favorable as the first option.

[Sathawale27]

In most of the cases we need to encode/decode full ByteArray to/from Base64. So, the length and offset seems perfectly fine after flags in order. I have one question in its implementation that, Can't we use Base64.encodeToString function? Which is already available in android API instead of encoding a ByteArray to byte[] and then toString with ASCII.

[JakeWharton]

Yep!

[jaredsburrows]

@romainguy @JakeWharton Review :)