Never scale nine-patches in ImageDecoder

Bug: 76448902
Bug: 70889348
Test: Manual + CtsThemeHostTestCases
(Ica5e7e81848c3880accee922ee6f1cc9e26262ca)

Scaling a nine-patch requires scaling its divs. When the scale factor is
not an integer, we have to round. This gets out of sync with the way the
decoder scaled the image, resulting in stretching or keeping fixed the
wrong portions of the image. Making this worse, when we scale down, we
end up with divs colliding with each other, and we have to arbitrarily
adjust them further so they do not collide.

NinePatchDrawable and the drawing code already know how to handle
drawing from the originally-sized image and do a better job stretching
appropriately, so allow them to do their job.

We already do something similar for Bitmaps created by ImageDecoder on
apps targeting P and above - instead of scaling them up, we allow the
BitmapDrawable's scaling code to handle density differences. We
preserved the old behavior (scale up) on apps targeting pre-P because
those apps may rely on the size of the Bitmap contained in a
BitmapDrawable without accounting for its density (see Bug: 74061412).
But that is not an issue for NinePatchDrawables, which do not allow
peeking at their internal Bitmaps.

Rewrite ImageDecoder.computeDensity. There is no need for it to be
static, since it takes an ImageDecoder as a parameter and reads its
fields, including the new field mIsNinePatch. Set mIsNinePatch in the
constructor to avoid another down call into native. Split up the
conditions that result in returning srcDensity without calling
setTargetSize for clarity.

Remove ImageDecoder constructor from the graylist. It was accidentally
added due to the fact that it is called transitively from public APIs.

Change-Id: I3c5ddd67f3352c991515f30ce1c477c9a608833f