Add generic folder to opd/4.3

When build.prop query (and certain other operations, search for 'generic')
fail, the patcher defaults to 'generic' and 'latest' patches. Here they did
not exist, so there was no files being adjusted. It is a bit of a mystery
why nothing got decompiled (it looks like it did not read the "files.txt") but
this should help.

The 'generic' folder is a symlink to 'aosp'. So anything the build.prop query
cannot resolve will default to aosp patches. That will have it fail loudly since
I expect AOSP patches to fail for PAC and PA (I have seen the build query fail
with both in this manner).

Try again with PAC, okay @Urinophoria?
Merge pull request #142 from Caldair/master

CM10.2 tabletUI initial release.
When multiple mods selected, all mods get matched through build query

This has been a big white whale, and the fix is so small.

This sends each individual mod through the build query one at a time, and
now matches each mod to the patch date most fitting for the rom's build date.
I had tried a couple things, but I was worried that Cygwin's bash wouldn't
support it. This should be fine, and looks to work great.
Add 4.3 support for PACman Roms and update cm-10.2 (0808)
Update "provisionals" for 4.3

There were some problems patching a few mako builds (in CdmaService again...)
so I updated the common provisionals we have had success with during 4.1 and
4.2.

These are smali files from STOCK builds, but builds from which we have made
patches. Since they are the source of the diff, we know that they will patch.
The result of using them is that whatever commit difference their rom has
with the source are backed out. That has the potential for a bad experience
so is best used sparingly. Generally it has been found to be okay with these
files, sometimes it is merely the register count (a smali decompiling protocol
not substantive)
Reenable the ability to specify PATCH_DATE manually (if multiple mods, only works for Pdroid-related mod)

The recent build-query fix overwrote this ability. I would like to add support where all patches could be
manually specified on the command-line, possiby seperated by commas like MODS. But there is a wrinkle. B/C of our "provisional"
usage (which copies over smali files) we have to ensure that the MOD that uses provisionals (only PDroid) is the first applied
because otherwise the danger exists of overwriting any earlier patches.

E.G. If we patch ActivityManager.smali for v6supercharger, and immediately afterwards copy over that same file as a provisional
for OpD, well then that update.zip will no longer work for v6.

Anyway, to add supportfor specifiying patch dates for multiple mods, the user would potentially be quite frustrated if they did not
know that the Pdroid-related mod had to be the first entered. A mechanism to take care of that for them would probably be best,
but would be very very complicated for something that is so unlikely to be used. Also, if we ever get to on-board patching, then
those very rare cases could just be handled by consecutive patches. So that may never happen, is the upshot of all this.
Add PA support for OPD
TEST
Merge pull request #144 from Urinophoria/master

TEST
Add 'latest' folder for aosp-ever

I am not even sure we are ever using the 'latest' folders as of the finalization
of the build query fixes. But better to safe, since there are several error
catches where it defaults to latest if it cannot find what it is looking for.

Great job on all these patches...learning how to do this and github in this
amount of time is no small thing. I had some very good luck when you decided
to join the project.
Whoops. We forgot to version up.

Versioning is pretty important for us in particular. Since the users get our
changes immediately, we need to be on the ball so we know exactly what changes
they have when they submit logs. If we just pushed a fix, we need to know
if the broken log they submit has the latest commits or not. I added a logline
that lists the latest commit but the version number is easier to keep track of.

The PATCHES_VERSION needs to be incremented every time you make a change in
either the patches_tools or patches directory. That is what determines if
batch.sh runs on the users machines. If they update to get evervolv support
but we haven;t incremented the PATCHES_VERSION number, then the user
will report that it isn;t working, cause it won't be.

You can usually just do these steps at the same time as adding the patches.
For now, try to only increment the 100th place, the second significant digit.
I will increment the first digit and the changelog when necessary. Thanks!
Added slim patches, and "latest" symlink.  incremented auto_patcher ver and date.  Think I got it all this time!
Merge pull request #145 from Urinophoria/master

Added slim patches, and "latest" symlink.  incremented auto_patcher ver ...
Add remade Mms.apk patch to Cm10

I have heard that our patches are working, excepting some Mms issues. That
would make sense, it hasn't been messed with since we switched to baksmali.
Here's hoping.
Change CM10 files.txt to reflect the baksmali use for Mms.apk

Files.txt is one of the most important files in the program...it tells the auto-patcher
which files to operate on and which tools to use. When the Mms.apk was giving me fits
(disappearing on everyone) I finally switched to using baksmali instead of apktool
that problem went away. As I was just testing the change, I only added it Cm10-1.
I found out it worked, but never ported it down to 4.1. The broken Mms was the result.

I also added a provisional I found useful. I intend to start a page on thewiki where we
build a knowledge-base of useable/not-usable provisional files. It will be MOD-specific,
but might give contributors an idea of where they can possibly fudge.