Sort colors from high count => low count

The colors were being sorted by population ascending, sorting by
population descending fixes a long-standing flaky test that became
a 100% reproducible failure once scaling fixes were introduced.

The test failure that caught this is CTS' WallpaperManagerTest's method
wallpaperColors_secondary. It creates a bitmap that is mostly red, with
a smaller area of blue.

Before the set of 4 CLs in this topic, when the wallpaper was downscaled
by WallpaperManager, it introduced new colors to the wallpaper due to
bilinear filtering and JPEG compression. With the new colors introduced
by scaling, the least popular color was blue enough to pass
WallpaperManagerTest's wallpaperColors_primary method, and the 2nd least
popular color was red enough to pass wallpaperColors_secondary.

With CLs for consistent image input to quantizers, namely 2 CLs, cache
wallpaper as PNG instead of JPEG, and only rescale the wallpaper if it
is greater than the display height, the scaling/JPEG artifacts are not
introduced, which then exposes the bug that primary/secondary were the
least popular/2nd least popular colors in the image, instead of the
most popular/2nd most popular, as intended.

Bug: 188373181
Test: atest CtsAppTestCases:android.app.cts.WallpaperManagerTest
#wallpaperColors_secondary --, use helper methods to store
the bitmap after downscaling to confirm introduction of new colors
before other CLs in this topic, use go/monetstudio to confirm
quantization results from that downscaled image. Check test against
all 4 CLs, confirm test starts failing once "Only rescale wallpaper if
its > display height" CL is introduced.

Change-Id: I143f824fbd961b81604d427a0570b3a171bdeb79