Add key triggers for safe mode during boot.

To disable Xposed during zygote startup:
- Make sure one of the VOLUME keys is held down before app_process starts
- 2 short vibrations will occur when the detection starts (zygote starting)
- press and release POWER or HOME twice, without releasing the VOLUME key that is held down
- release the VOLUME key
- 2 short vibrations will signal that the combo was detected and the disabler file will be created

To enable Xposed, the same steps can be executed but with three presses of POWER/HOME instead of two.
Three vibrations will occur if this was triggered.

If VOLUME was pressed but no valid combination occurs within 10 seconds, a single vibration will
signal that an invalid combination was used.
Remove key trigger to re-enable Xposed
New logic for safemode detection, based on a single key being pressed multiple times.

Upon startup, one of the physical keys must be pressed during the first 2 seconds (or already
held down upfront).
After that, the same key must be pressed again within 5 seconds, until 5 total presses are reached.

Two short vibrations are issued when the initial key is detected, and an additional short vibration
for every subsequent key press.
If the trigger is successful, a long vibration is issued.
Don't trigger safemode if more than one key is pressed initially
Safemode code revision and documentation
Added "safemode_disable" flag file to prevent disabling Xposed with the safemode key sequence during Zygote startup.
If the file exists, safemode detection will be entirely disabled.
Beautifying
v48: Gracefully handle overlong CLASSPATH

Fixes #4
Merge branch 'safemode'
v49: Safemode
v50: Log build fingerprint
Merge branch 'upstream'
v51: Make specific objects public instead of nuking access checks

There were just a few issues with the nuked access checks. Most of
them were caused by invalid smali edits (e.g. invoke-virtual for
direct methods), but under some very rare conditions, even apps
which did everything right could crash.

The implementation divides the list of classes/methods/fields to be
made public from the code that performs these changes. This might
become useful for further maintenance and ART support.

Fixes #5.
v52: Add a method to change an object's class

This must be used very carefully. Internal use only, not for modules.
v53: Add debugging method to dump object
v54: Add an internal method to clone object to subclasses

See XposedBridge commit for details.
Merge branch 'upstream'
v55: Don't load Xposed for commandline tools

Examples for such tools are "am" and "pm".

The IXposedHookCmdInit / initCmdApp() API was only used by two modules in the
in the repository, and both of them actually didn't need it (and therefore
removed it now). So let's not execute our code unnecessarily. It also reduces
the logging, which is good because log lines of Zygote and tools could mix up
and confuse users.

It's still possible to enable processing by creating a file, whoever no UI
option is planned. It's mainly for testing very low-level changes in Xposed.
Clear exceptions after registering natives failed
v56: No longer make classes/methods/field public

Thanks to recent changes in the Java part (e.g. using more reflection,
overriding different methods), this is no longer necessary.