Consistent "low storage" behavior.

When answering the question "how much space is free", use the same
logic for Settings UI and StorageManager.getAllocatableBytes().  That
is, the reported free space is usable bytes plus any cached data the
system is willing to delete automatically.

This does *not* include any reserved cache space, since we don't want
abusive apps to penalize other well-behaved apps that are storing
their data in cache locations.  Callers freeing cached data need to
now explicitly request defiance of the reserved cache space.  (Most
callers are already doing this by using FLAG_ALLOCATE_AGGRESSIVE.)

Rewrite the core logic of DeviceStorageMonitorService to understand
this new "reserved" cache space, and to be easier to understand.  It
also now handles cached data on adopted storage volumes, which had
been ignored until now.  Also fix bug where we had skipped "low"
broadcasts when the device skipped directly from/to "full" state.

Bug: 38008706
Test: cts-tradefed run commandAndExit cts-dev -m CtsJobSchedulerTestCases -t android.jobscheduler.cts.StorageConstraintTest
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Change-Id: Icbdcf3b52775f7ada1ceaeff2f96094c8d8052f9