Migrate StrictJarVerifier and ShortcutPackageInfo to java.util.Base64

Previously, they weres using libcore.io.Base64, which is @deprecated.

The two implementations' encoders produce the exact same result.

The two implementations' decoders' behavior differs for malformed
input:
 - In case of error, libcore.io.Base64.decode() returns null while
   java.util.Base64.getDecoder().decode() throws.
 - java.util.Base64 tends to be stricter about rejecting malformed
   input; specifically, it allows neither whitespace nor unexpected
   '=' characters (should only occur in the padding) whereas
   libcore.io.Base64.decode() leniently allows them throughout the
   input.
 - if the input terminates prematurely, libcore.io.Base64 tends to
   return fewer bytes (stops at a four byte boundary).

The behavior differences for malformed Base64 encoded data should
not affect ShortcutPackageInfo because it should only need to deal
with XML attribute values written by itself, which are well-formed.
Note that this CL does not lead to any known changes of the encoding
step, so values written by earlier versions should not cause problems
when read by later versions of ShortcutPackageInfo.

StrictJarVerifier may now reject or behave differently for .jar /
.zip files with malformed attribute values but this seems okay since,
per its name, it is meant to be strict. For example, after this CL,
StrictJarVerifier will no longer accept algorithm + "-Digest"
attribute values with extra whitespace or padding characters as valid.

Test: Confirmed that the two implementations' encoders produce the
      same result by running the following code just before this CL:
      assertEquals(
          libcore.io.Base64.encode(allBytes()),
          Base64.getEncoder().encodeToString(allBytes()));
      where allBytes() returns a byte[] with values (byte) 0 .. (byte) 255
Test: Test that phone still boots after flashing code that includes
      this CL.
Test: CtsLibcoreTestCases

Bug: 31292683

Change-Id: I775d32f329f693514a8f14d87e1ef0d7a757e6c3