Remove AndroidFuture from ShortcutService's internal api

AndroidFuture is not meant to be used as a return type, this CL removes
the cases where AndroidFuture is used as a return type.

After closely scrutinize some of the api are not required to be async
in system level to support AppSearch integration in the future.

Here's the list of API that can was previously made async at
service-level but could actually stay synchronous:
- setDynamicShortcuts/addDynamicShortcuts: Dynamic shortcuts are stored
in system ram only unless it is also a long-lived shortcut, yet long-lived
shortcuts are persisted into AppSearch in a separate background thread,
client process should not need to wait for writing to AppSearch to finish.

- updateShortcuts: Long-lived shortcuts that lives in AppSearch might
be updated by this api, but similar to
setDynamicShortcuts/addDynamicShortcuts client process is not required
to wait for writing to AppSearch to finish.

- removeDynamicShortcuts/removeAllDynamicShortcuts: The method signature
doesn't return anything in the first place, so client process is not
required to wait for AppSearch.

- disableShortcuts/enableShortcuts: Similarily, since the method
signature doesn't return anything, client process is not required to
wait for AppSearch.

- reportShortcutUsed/onApplicationActive/applyRestore: No return type.

- removeLongLivedShortcut: The operation itself should be async, but
since it has no return type, client process is not required to wait.

API that should become async at service level but remain sync in client
process are:
- requestPinShortcut: To support drag and drop from AllApps+, client
process should be waiting for the pin request to complete since
long-lived shortcuts that doesn't exists in system memory might still
be surfaced in AllApps+. Since read from AppSearch is async, the client
process will need to wait for the read to finish synchrounously.

- createShortcutResultIntent: Similarily, a client process might call
this api to launch a long-lived shortcut that doesn't exists in system
memory. So the client process needs to wait for read from AppSearch to
finish.

API that should be async but is not covered in this CL
- getShareTargets: Sharing shortcuts could be potentially backed up
long-lived shortcuts that doesn't live in system ram, but this api is
already being used by PeopleService, thus should be covered in a
separate CL as it would need to be reviewed by another team.

Bug: 197277083
Test: atest ShortcutManagerTest1 ShortcutManagerTest2 ShortcutManagerTest3 ShortcutManagerTest4 ShortcutManagerTest5 ShortcutManagerTest6 ShortcutManagerTest7 ShortcutManagerTest8 ShortcutManagerTest9 ShortcutManagerTest10 ShortcutManagerTest11
Test: atest CtsShortcutManagerTestCases
Change-Id: I8970cc77073d329fe00a349d9fa190f917b7851d