Inline unnecessary task on CrOS memory pressure

Now that performance manager runs on the UI thread, posting a task to
the UI thread to get the reclaim target is redundant and just introduces
extra latency.

Posting the task has been unnecessary for a while, anyway. The posted
task was originally written to work with the non-thread-safe lacros
evaluator. However, getting the reclaim target from the ash evaluator
has always been thread safe, so posting the task has been unnecessary
for a while.

On ChromeOS, this delay is captured by the Discarding.DiscardLatency
metric, which shows a 99th percentile latency between receiving the
pressure signal and discarding the first tab of about 2.5 seconds. Based
on local testing with the multivm.Lifecycle.host_with_bg_arc_vmmms test,
this is almost entirely due to delays caused by dispatching tasks on the
Chrome main thread. With this change, the long tail latency is reduced
from >5 seconds (as high as 16 seconds was observed) down to <250ms.

Change-Id: If94e2d3eebcb7dae1f9d9c88dd30654b2d3697f2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6805091
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Francois Pierre Doray <fdoray@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1496670}