Updated README with links
Ensure proper compilations without git
Module can now be configured via SettingsActivity

In order to expand the number of modifications XHangouts can support a
runtime settings panel becomes a necessity. For example, people may
desire the MMS resizing functionality but any visual modifications may
be unwelcome. In a module capable of multiple modifications it makes
sense to offer options.

Adding an Android PreferenceActivity to an Xposed module is trivial, as
it is with any other Android app. The problems start to spring up when
you attempt to read these values from the actual Xposed module class.
XposedBridge provides an XSharedPreferences class, which appeared to be
a godsend, that allows for easy read-only access to a given Android XML
preferences file. Five hours and a thread on XDA later, I came to the
conclusion that XSharedPreferences wasn't a viable solution. Why?
First, it's only available in classes directly loaded by Xposed *when*
they are loaded by Xposed. I tried loading in the XposedBridge.jar
manually via DexClassLoader and good-ole reflection. While that sorta
worked, I quickly ran into the second problem. The Google Hangouts
package does not have permissions to read my XHangouts preferences
file. By default it is given the MODE_PRIVATE permission allowing
access only to XHangouts itself. The only solution to this would be to
place the preferences file elsewhere (bad) or make it
MODE_WORLD_READABLE (less bad, but deprecated in JB 4.2). Those two
solutions (workarounds?) might not even be possible with a standard
Android PreferenceActivity. A big issue with the world readable method
is that there's absolutely no guarantee this permission would stick.

The issue with the previously explored approaches lies in the false
assumption that the module is one cohesive application. We have
XHangouts which is instantiated exclusively by Xposed and contains code
which is run in multiple contexts. And then we have everything else,
that works as any Android app would. XHangouts has code that, while
part of the same physical package, runs within at least two entirely
separate processes. The XHangouts process, briefly for the isActive
hook, and Google Hangouts, for nearly everything else. Using a static
initializer to load the settings is super dangerous (but seems super
convenient) because we can't be certain under what process we're
actually initializing. And even if we could (I haven't tried) it
doesn't matter as it won't work anyway if we're initializing in the
Google Hangouts process. I did try to instantiate the XHangouts class
super early with system permissions by implementing the Xposed Zygote
hook. This worked beautifully until I needed to reload the permissions
or read from the file again from inside the Google Hangouts code. I
gave up on that potential breakthrough after at least another half
hour.

So what's a poor Xposed module dev to do? Fire up your ContentResolver;
we're going to abstract. We need to use one of Android's IPC methods to
handle the talking between the GHangouts and the XHangouts process. The
idea is to wrap a SharedPreferences instance within a ContentProvider.
Since we can't actually pass the object itself through IPC, we'll have
to abstract SharedPreferences methods in the ContentProvider query. I
just did a single read-only implementation, as that's all I needed.
The GHangouts process reaches out to the OS. OS fires up the XHangouts
process. XHangouts proc opens up the preferences file which it actually
owns, and feeds the data back to GHangouts via Cursor. Right now there
are no permissions set up so any app can query XHangouts for settings
data, but it's not a big deal for our purposes. There's nothing
remotely sensitive. I have not experimented with the multiprocess
AndroidManifest flag which might decrease overhead if set to true.

Well that only took forever. I hope I used that semicolon correctly...
Push versionCode/Name to 2 and 1.1 respectively