[1/n] OomAdjuster implementation correctness and efficiency overhaul

This CL introduced the new OomAdjuster algorithm.

The previous OomAdjuster uses a recursive algorithm to evaluate
the given target process's client process in order to compute
the right oom adj scores for the target process, yet it's inefficient
in dealing with cycles and may yield unexpected result with different
order of the inputs. Based on the rationale that, apps can't promote
the service/provider it connects to, to a higher bucket than itself.
We're getting rid of the reursive way and introducing a new bucket
based algorithm. See the details in OomAdjuster.md.

More tunings and refactoring on the way, such as reducing the amount
of full oomadj update.

It's turned OFF by default as of now. To enable:

$ setprop persist.sys.activity_manager_native_boot.enable_new_oom_adj true

Bug: 275071719
Test: atest CtsAppTestCases
Test: atest FrameworksMockingServicesTests:MockingOomAdjusterTests
Change-Id: I8cd8310d964a2b6f0ca48416ae34e7266b3357ac