The "apply" DSL method can be called from patch-do blocks to specify
the paths within an archive of the desired patch files, which will be
applied in the order in which they were supplied to the "apply" calls.
If "apply" isn't used, raise an error whenever the extracted directory
doesn't contain exactly one file.

The "apply" method can be called zero or more times within a patch-do
block with the following syntaxes supported:

    apply "single_apply"
    apply "multiple_apply_1", "multiple_apply_2"
    apply [array_of_apply]

If apply must be used, a single call using the second syntax above is
usually best practice. Each apply leaf should be the relative path to a
specific patch file in the extracted directory.

For example, if extracting this-v123-patches.tar.gz gives you

    this-123
    this-123/.DS_Store
    this-123/LICENSE.txt
    this-123/patches
    this-123/patches/A.diff
    this-123/patches/B.diff
    this-123/patches/C.diff
    this-123/README.txt

and you want to apply only B.diff and C.diff, then you need to use
"patches/B.diff" and "patches/C.diff" for the lowest-level apply leaves.

The code was provided by Xu Cheng. Any mistakes are mine.

I inadvertently gzipped it last night. That in itself doesn't cause any
tests to fail because the download strategy code is robust, but it's
fixed here anyway to be consistent. Basically, I'm dumb.

I also took the opportunity to remove the other resource fork file, so
the tarball is clean.

Signed-off-by: Jack Nagel <jacknagel@gmail.com>

The test_a_basic_install was failing because it expected
libexec.children.length to be 1, when in fact there were two files in
the untarred libexec: NOOP, and the Mac OS X resource fork file ._NOOP.

That file is now removed, and the test passes.

Signed-off-by: Jack Nagel <jacknagel@gmail.com>