This implementation follows the implementation of ZipDecompressor with the
exception that .7z files do not handle symbolic links or preserving file
permissions.  The commit 9c98120 where
.ar/.deb support was added, was used as a reference for what additional files
to change.

Closes #27231

The test was using the same decompressed output directory that other tests were
using, a generic "out" directory. So test results were verifying/depending on
the output of those other tests.  Now the test uses /* outDirName= */
this.getClass().getSimpleName()

Fixing that revealed that the expected decompressed file was named wrong:

wrong: root_folder/another_folder/regular_file
right: root_folder/another_folder/regularFile

Instead of using `archiveDescriptor.assertOutputFiles`, which relied on the
output of other tests, we now inline the exact assertions we need.

Previously, the assertions would check that a file's `exists()` method was
true. This didn't produce the most friendly test output.  For example:

> value of: exists()
> expected to be false

Now we get a directory listing of entries and check for the file in that list:

> expected to contain: myfile
> but was            : [regularFile, renamedFile]

For the unicode test, we now make use of `StringEncoding::internalToUnicode`
when reading directory entries and `StringEncoding::unicodeToInternal` when
checking for a files existence. This is because meteorcloudy@ reported that
internal tests failed, which I am making an educated guess that it has
something to do with the string encoding.

Each test was using the same output directory for the decompressed files (was this.getClass().getSimpleName()).
This would cause problems as the decompression of files in one test would affect other tests.

Now each test creates their own TestArchiveDescriptor with the output directory being set to:

> this.getClass().getSimpleName() + "_" + name.getMethodName()

As an example, for `testDecompressWithRenamedFiles` the directory would be:

> SevenZDecompressorTest_testDecompressWithRenamedFiles

…formToInternal

I have no idea what I'm doing - in this case, it seems like using the platform
variant is better since it checks if encoding/reencoding on a platform is
needed at all before doing the encoding.  Seems safer than the previous calls.

This is all being done because internal testing is failing on this change and I
have no clue what is different internally since I don't work at Google.

…orm/platformToInternal"

This reverts commit 4950332.

Per fmeum: since you are passing the result to the Truth assertion libraries,
which expect regular Java Unicode strings

See discussion in #27269 - there was some internal testing difference for
unicode files that we weren't able to figure out.  It works locally on my local
mac computer but did not work inside Google for some reason.  Since this is the
only decompression test that tried to test unicode files, we decided to drop
it.  The thinking is that this would also occur in the other decompression
tests if they also had a unicode file.  My own integration testing shows that
it does work.