More robust createAppData() batching.

The perf team noticed that createAppData() is pretty slow, holding up
typical device boot timings because it loops over all installed apps
twice (once for DE, once for CE storage), making blocking installd
calls for each individual app.

There was a createAppDataBatched() method added awhile back, but it
was only wired up for multi-user initialization, and it was fragile
because any failure in the batch would leave the device in a
non-deterministic state.

This change rewrites the installd batch call to return a unique
result object for each request, allowing us to share both detailed
success (returning CE inode values) and detailed error messages,
instead of failing the entire batch request.

On the framework side, we use CompletableFuture to collect multiple
requests for batching, while also allowing "chaining" of follow-up
work, which PackageManagerService heavily relies upon.  (For example,
when a specific package fails, we might want to try destroying and
recreating its data directories.)

Bug: 163861619
Test: atest FrameworksServicesTests:com.android.server.pm
Test: atest android.appsecurity.cts.DirectBootHostTest
Change-Id: Ib903dbbbe98fa453c8a3500338824064ae64f80f