Optimize gradient textures

Compute the size of the backing textures based on the maximum possible
number of shades in the gradient.

Change-Id: I2d7f20477d31b81e9735f2c1d83ebdd0dbcbe340
Plug memory leak that happens when reusing display lists Bug #7195815

We did not reclaim resources when reusing an existing DisplayList to
record a new empty list of commands. This would lead to various memory
leaks: bitmaps, paints, paths, matrices, etc.

This is not a common case but some apps run into this situation,
such as Launcher.

Change-Id: I2eb14ac86a212123f8edbe42b70a7c1c51fa4145

Conflicts:
	libs/hwui/DisplayListRenderer.cpp
Fix memory corruption in LayerRenderer::copyLayer

The pixel store pack alignment was not set for the source texture,
causing a write to occur outside of the destination bitmap's
bounds.

Change-Id: Iaa5767acf7b5943fbc2765c3810a142f06b1a796

Conflicts:
	tests/HwAccelerationTest/AndroidManifest.xml
Fix texture corruption

When memory gets low on a device, activities flush everything they can.
Hardware-accelerated activites, such as Launcher, flush GL resources and destroy
the GL context. However, some resources were still hanging around, due to deferred
destruction policies (we don't delete layers until the DisplayLists they are in
are finalized, to ensure we don't deref deleted objects). This meant that we were
referring to obsolete GL data in these objects. in particular, it meant that we might
come around later, after a new GL context was created, and delete a texture object
that was incorrect. We use the layer's "texture id" to refer to the texture underlying the
layer. But if there's a new GL context, then this texture ID is no longer valid, and
we may be deleting the texture that a different object (layer, icon, whatever) is referring
to, because the driver may return that same ID under the new GL context.

The fix is to more aggressively delete things that we know will not be used again
when the GL context is destroyed. In particular, we delete all resources being used
by all DisplayLists at GL context destruction time.

Issue #7195815 Textures corruption on all devices, in many apps

Change-Id: I52d2d208173690dbb794a83402d38f14ea4c6c22
Allow purging of asset bitmaps

It seems that neither CM9 nor CM10.x includes the actual framework-side
code to facilitate user-controllable bitmap purging. Odd, since the
CyanogenMod Settings app in both CM9/CM10.x includes the option.

Backported from original Gingerbread commit:
http://review.cyanogenmod.org/#/c/3908

Original description:

Allow the system to reclaim more free RAM when needed on 'low' memory devices
(e.g. Droid/Milestone) that are struggling with 2.3. This option enabled
efectively restores the froyo way of forcePurgeable BitmapFactory asset
handling.

Change-Id: I6a3b8a05b7be9c214a8548d6c6d1621e6533a1e0