front: Enabled virtual gamepad image sharing
An optional parameter "images" can now be specified in the "INFO" section.
When specified, button and mask images will be pulled from that folder
(allowing layouts to contain only a pad.ini file, and reducing space).
Old custom layouts are still backward compatible. Additionally, I added an
all buttons layout.  "Small" and "Tiny" layouts do not currently work
(These will be replaced by image scaling in the next commit).
front: Implemented virtual gamepad scaling
I added two new optional parameters to the INFO section of pad.ini for virtual gamepad layouts.  These parameters specify the intended width in both pixels and inches.  The auto-scaling uses these to adjust image sizes to the target device.  This is still pretty rough, but the basic functionality is in place.  The default pixelWidth and inchWidth for the gamepad layouts will likely need to be adjusted (I based the numbers off of my old Droid X, just to make sure the auto-scaling was working).  I haven't implemented separate logic for Tablets or portrait modes yet.
front: Implemented FPS scaling
The FPS indicator has a new parameter minPixels, which indicates the smallest size the FPS indicator should be scaled (any smaller and the numbers would not be readable).  Also, renamed a couple parameters to better indicate how they are used in the scaling calculations, and set the default values to an acceptable size.
front: Added option for shaded touch controls
A number of users have requested this option, and since the images are now separated from the layouts, it is an easy addition.
front: Added support for tablets and portrait mode

Required adding two additional layouts with all buttons visible.  The
tablet layouts are doubled in scale for phones in portrait mode (because
the buttons are otherwise far too tiny).  Will need to test on a variety
of screen sizes to make sure there is no button overlap.  I believe this
new system is ready for testing.
Merge branch 'master'...

Merge branch 'master' into 'paulscode/virtual-gamepad-changes'

Conflicts:
	res/values/strings.xml
	src/paulscode/android/mupen64plusae/MainActivity.java
	src/paulscode/android/mupen64plusae/input/map/TouchMap.java
	src/paulscode/android/mupen64plusae/input/map/VisibleTouchMap.java
	src/paulscode/android/mupen64plusae/util/Utility.java
front: Fixed potential NPE

I'm not sure why there was a null numeral, though.  The reported crash
could be indicative of a problem elsewhere (or it could be normal - I'll
have to study the code further)
front: Fixed cause of incorrectly scaled FPS
front: Base portrait scale off longest side

Rather than up-scaling from the shortest side in portrait mode,
scale is now always calculated from the longest side.  This allows
the controls to be consitently sized in either orientation.  This
also resulted in the controls being a tad larger in portrait mode,
so to better fit the D-Pad in the "Both" layout, I moved the L and
Z buttons up 2%.  Will need to re-test on a range of device sizes
and resolutions.
Merge branch 'master' into paulscode/virtual-gamepad-changes
OUYA: Added interfaces in preparation for IAP

In-app purchases, which is how donations will be collected
in the OUYA version of the app, are all done through an OuyaFacade
instance and utilize encryption.  This commit lays the groundwork
for that functionality.
OUYA: Corrected comment typos
OUYA: Added interface for querying product info

Because this information is requested from the server, the
response is acynchronous.  Mirroring the ODK, I created a listener
interface which you pass allong with the request to handle the
response.
OUYA: Return after invoking callbacks

This fixes a bug where the onFailure callback was always invoked, even
when there wasn't a problem.
wip
front: Add pref for additional touchmap scaling

An additional .5 - 2.0 scaling factor can be applied to the final
calculated scale, to give the user a wide range of possible scales
to suit their style.
front: Removed unused import
bugfix: Only register vibrator if it is useable.

All devices prior to Honeycomb were assumed to have a vibrator. Since
Honeycomb, many devices don't have a vibrator.  To maintain backwards
compatibility, Honeycomb+ devices always return a non-NULL Vibrator
object, even if they don't actually have vibration hardware. Instead,
you must specifically query whether the vibrator actually exists.

I tested this on a Gingerbread device to verify that the ternary state-
ment is safe on non-Honeycomb devices.  It was safe for my device.
bugfix: SeekBarPreference keeps value on rotation, and cleanup.

Two small bugfixes:
 - onDialogClosed: callChangeListener is called on the correct value
 - onSaveInstanceState: the correct value is cached

The change on line 270 is purely cosmetic; I found it slightly easier
to read the code.

Tweaked some comments for clarity.
assets: Add stock autohold images, move touchpad images to images dir.

I placed some alternate versions and other related images in the docs
folder.