Refactor LogBuffer to no longer use threads/locks

Previously, we were spinning up a new logging thread for each log
buffer. Each thread would maintain a queue of work and pull items off to
be logged as they came in.

In the old system, the "loggability" of a buffer or tag was determined
on-demand. If a new tag came in that we hadn't seen before, we check
GlobalSettings to see if we had an entry for that tag. This (a) resulted
in a bunch of needless reads of Settings and (b) required a blocking IPC
each time we needed to perform a read (thus the need to offload the work
to background threads).

In the new system, all "loggability" overrides are read once, when
SystemUI starts up. The actual act of checking the loggability of an
individual tag or buffer is no longer blocking, and so can be done
without the need for a background thread. The one downside to this
approach is that there is a period, at the very beginning of SystemUI
startup, in which the overrides have not yet been loaded. A future CL
may create a temporary buffer that messages can be held in while waiting
for this initial read.

Finally, this CL creates a new statusbar command that can be used to
manipulate and view echoing overrides. Developers no longer need to
write directly to global settings

Flag: None
Bug: 235365671
Test: atest
Change-Id: I974da6a3651a2c7f3f2e2dd02f6748c4b63a5750