Themes: Only process themes that are applied during boot

Currently, the PackageManagerService will process all themes and
ensure their resources are compiled and available to the system.
This is highly inefficient and can bog the system down when booting.

This patch will only process the themes that are currently applied
durring boot and lets the ThemeService take care of queuing up the
others for processing.   This reduces boot time considerably,
especially when the user has many themes installed.

Change-Id: I52168a1751ad3bfc458048dd1558ad71cc16317a

Conflicts:

	services/java/com/android/server/pm/PackageManagerService.java
Fix attribute resolution in theme lookup

[Fixes Known Issues]
1. (CM) Chrome beta crashing w/ Hexo applied and menu button is pressed.
2. (AOSP) TextAppearance - fontFamily attr is incorrect (looked up in wrong package!) when
    a string value is defined in a style, and that style is set as the app's theme.

[Terminology]
1) Theme:    is the standard android definition of a theme.
             e.g in your manifest you may set android:theme="@style/foo"
2) CM-Theme: will be a Cyanogen theme. e.g. "Hexo"

3) Block: Also called index. Can be considered the cookie or ID to lookup a package in the resources.
          When a CM-Theme is applied, block 0 is framework, block 1 is the app, and block 2 is the
          CM-Theme.

[Background]
When a value for an attribute has not been found, the last resort is to look at a theme's base value.
This is done by using theme->getAttribute(...) which will return the value. The value is
unresolved if its a reference type. The block value will also be returned.

Since the value may be a reference and therefore unresolved, a call is then made to
ResTable::resolveReference(..) to do the final resolution. As part of its input, resolveReference
takes a block as a starting point.

In the case where resolveReference(...) is asked to resolve something that is not a reference,
for example, a string type, then it will simply return the same value and block. *Important* The block
value is then saved for the next call to get an attribute value. So if this block value is wrong
it will remain incorrect.

Therefore if resolveReference is passed the wrong starting block with a string value, then the wrong
block will be returned.

[Example]
1. 0x0101009b (android:attr/textColorLink) is first attribute to be looked up.
2. textColorLink has a value of 0x01020123 which maps to theme id 0x01020111. The block for theme
is "2" so block is set to 2. The value for this attribute is put into the array.
3. 0x010103ac (android:attr/fontFamily) is the next attribute to be looked up.
4. fontFamily is found in the theme as type string. The value is 0x7b9 (1977) and newblock variable
   is set to 1 since this value is found in the app's string pool. The block variable still == 2.
5. resolveReference() is called with block=2. The function does nothing and returns block=2.
   The fontFamily thus is stored wtih value=1977 and a block value of "2" instead of "0".

Change-Id: I2b979911b1b8ffb79c4cf310ae60682c84c11fcb
Themes: Let ThemeService handle all theme processing [1/3]

Only themes that are applied will be processed inside of the
PackageManagerService, all others will be sent off to the
ThemeService.

Change-Id: I5f2ec628e1d22a05accc6727efb0c1387455f82f

Conflicts:

	core/res/AndroidManifest.xml
	core/res/res/values/cm_strings.xml
	core/res/res/values/symbols.xml
WallpaperCropper: respect max wallpaper width

Some devices with high resolution screen only support 2048px wide
wallpaper (used to be fixed in I5b25bd931db0b2610e260921f28b92d8b0966aa6)

Pre-KitKat this works as follows:

- Launcher calls WallpaperManager.suggestDesiredDimensions and we
  limit the maximum size in that function
- The wallpaper setting application calls WallpaperManager
  .getDesiredMinimumWidth and respects that size

However, after KitKat, it is all broken because WallpaperCropper
now calculate its own dimension and does respect the value set by
getDesiredMinimumWidth (and it calls suggestDesiredDimensions,
which is supposed to be reserved for Launchers!)

Attempting to restore wallpaper setting by:

- Having WallpaperCropper respect config_wallpaperMaxWidth
- Having CMWallpaper (which copy pasted code from WallpaperCropper)
  respect getDesiredMinimumWidth
- For third party applications, if they respect getDesiredMinimumWidth,
  then they will work, but if they don't (i.e. uses WallpaperCropper's
  code), then there's nothing we can do.

Change-Id: Ib7da12a1c70befbeef2f305593d3841acbc45243