Add provisional that allows support for certain off-brand PA roms

This is a test. User response will tell us ho it goes.
Change files.txt symbol on the baksmali'd apks from "~" to "@"

Originally, all *apk files were decompiled with apktool. I added the ability
to decompile apks using baksmali binary instead, by prefacing the apk file
with a tilde (in the files.txt). However...

Cygwin was using shell expansion on the tilde and looking for the Mms file
in the home directory. So I have used a(n unfortunately unrelated) new symbol.
Now the question becomes, was this latest "disappearing" Mms.apk fix fools gold,
 since they may just have seen their original in the app drawer. Argggggh.
Merge branch 'master' of https://github.com/mateor/auto-patcher
Hide the "tpu not found" errors in Cygwin

Cygwin is not a full unix environment, and does not always have access to all
the utilities by default. Turns out tput is one of those. Put I am just
using that to output some color to the successful patching, trying to cut
down on the erroneous bug reports. This redirects to stderr.
Change leftover tilde to @ for baksmali's apks

This was removing Mms.apk from scope and not patching it.
Fix function to prioritize "pdroid"-type mods

This function was meant to take any list of requested mods, and re-order them with
any "pdroid"-type mods to be applied first. This is needed because of the "provisional"
use--where we sometimes copy over smali files we know will patch for troublesome roms.

Since copying over smali files would clobber any patches applied before the copy, it
was important to make sure pdroid went first. Provisionals can be dangerous, this is
a safety measure. Anyway, looks like there was at least two bugs. I am not sure when they
got introduced, I believe this used to work. Should also allow me to reinstate the
CONFLICTS function Caldair found was causing problems. We will see about that.
Add symlink called 20130516 linked to 20130403

This allows the Final release hack (the BID_OVERRIDE hard-set to 0516) to work for
tabletUI as well. This should allow all mods to apply to Final CM builds without any
further user specification.
Versioning to v2.9927 and uupdate changelog
Fix CONFLICTS function

When using rom probe, the CONFLICTS function did not iterate through the mod
list. So if there were multiple mods and no rom type specified, the conflicts
function would only work on the first mod in the list, generally hard-coded
to be a PDroid mod.

This updated version of the fix resets the PID variable, so each call to the "mods_info"
function sets the various mod-related variables as set to each individual mod. The
PID array (which is the list of requested mods set at the CLI) is afterwards reset to the
ordered list made previously (SPID array).

Someday all of these various variables and arrays need to be sensibly renamed.

Closes (#125)
Merge branch 'update_conflicts' and version up
Be more explicit about Final CMID

Some nightlies for devices with slightly non-standard build.props were
triggering Final build status (used to be "10.1.*", changed it to
("10.1.1" || "10.1.2") )

Devices include encore (still needs manual date selection) and i9100 (fixed),
among possible others.
Manual date specification on CLI was failing

This was caused by removing the $P variable yesterday. We need to rewrite our
variable names, as being haphazrd with them has left us with problems of scope.
Some of these problems are very hard to find because they have variable set
elsewhere and we don't even know it.

Previously, ./auto_patcher encore.zip openpdroid cm 20130516 was failing
because the script was checking for [ -d patches/$P/$ANDR/$RID/$BID ]. But
$P was no longer defined, because I changed it yesterday. But we did not know
that was where we had set $P for this function, that was an accident. This is
how the most frustrating bugs come to be, scope and variable confusion.
Rename variable in loop to finish yesterdays rename (h/t: gcydtmkq)

Affects the "helpful" output I spent so much time writing. Whoops.
Version up to 2.9.9271
New 0719 OPD CM patches; version to 2.9.93
Close big bug in Incremental function

Incremental patches are in place as a method to deliver hotfixes. If we have
some reasonably small change we wanted to make to a big mod like openpdroid, we
would build one patched OPD, and then one patched + the bugfix. The resulting
diff becomes a single feature patch. You can see this at work with
services-gp-fix.patch in Openpdroid.

However, I just saw that there is a big bug. We apply patches in the program,
and send the output to a temp file (JAR.log). We then scan that file for a
FAILED string, and if found it triggers our provisional or returns a failed
patch and exits. When applying the original INCREMENTAL patches, we were
overwriting the JAR.log and all alerts of a FAILED patch.

Simply changing the INCREMENTAL patches from ">" (overwrite) to ">>" (append)
solves this issue.

Big bug, though. Generally speaking, if this had been causing problems, we
would have already known because services.jar would have refused to compile
(which is how I found out about it) or we would have reports of boot loops. But
eventually, the upstream services.jar would have changed to the point we would
have gotten reports. It would have been hard to track a boot loop, glad it is
found now.
Merge remote-tracking branch 'upstream/master'