Stop double-counting native memory in graphics classes

Bug: 121304803
Test: Infeasible

Previously, the NativeAllocationRegistry needed to report how much
native memory was being held onto by the Java class in order to get a
more accurate count of how much memory was in use. But recent changes
allow the system to have an even more accurate view of the native memory
with mallinfo(). Further, the AOSP change
Idccb8b50d26c8c3e93cc34040d784f74dfcdbf51 introduces new APIs that allow
distinguishing between large native malloc allocations, which should
cause more frequent mallinfo() checks, and whose sizes need be available
to ahat etc, and smaller native malloc allocations.

Bitmap and AnimatedImageDrawable use the version for large native malloc
allocations. The rest pass an implied size of 0. Note that many of the
old Registries used somewhat arbitrary sizes, reinforcing the fact that
the new way of keeping track of this is better.

Add Bitmap::pixelStorageType to differentiate between types of memory
that should be accounted for by the Registry.

Update Bitmap::getAllocationByteCount to report the actual size of
ashmem allocation.

Fix a typo in LineBreaker.java, discovered while looking to find
existing callers of Bitmap's constructor.

Change-Id: I57c407258450aeaf08b47df32432466639d9faed