Nuanced Uri handling related to WM/AM locking.

As part of detangling WM/AM locks, we added a Slog.wtf() to identify
and lurking cases where we tried resolveActivity() with the WM lock
held.  This helped us uncover startActivityFromRecents(), but the
logic there is unfortunately too risky to refactor.

Instead, this change narrows our locking detection to only consider
cases where we'd actually risk a deadlock; that is, when the thread
is holding the WM lock and we're just about to acquire the AM lock.

This change now avoids deadlock completely by assuming that we can't
check Uri permissions in these cases where we know a deadlock is
imminent; we instead use a safe-default that the Uri permission is
denied, and Slog.wtf() to identify which paths are triggering it.

The only path we've identified so far that triggers this logic is
startActivityFromRecents() which can be reproduced by re-launching
a recent task after a device reboot, which when combined with Uris
that require "forceUriPermissions" is a very rare situation.

Bug: 159937485, 115619667
Test: manual
Change-Id: I4ed1c402703e0772c0164ac0acc64f3a754512f3