Use a separate fingerprint for DefaultPermissionGrantPolicy.

History here is that initially DefaultPermissionGrantPolicy and
RuntimePermissionsUpgradeController were both using Build.FINGERPRINT
as the fingerprint to determine if they need to re-run, because they
both can only change upon OTAs. Then when we made PermissionController
updatable via Mainline, we added PermissionController version code to
that fingerprint and started calling it extended fingerprint. That
made sure RuntimePermissionsUpgradeController can run upon
PermissionController upgrade, but also unnecessarily re-runs
DefaultPermissionGrantPolicy as the platform class itself and
preloaded apps can't change without an OTA.

In the new subsystem, we are moving the functionality of
RuntimePermissionsUpgradeController back into system server because it
has been a performance bottleneck, and we also no longer need the
existing fingerprint for it because we can now directly let the
upgrade logic check if the permission state is latest (this other
numeric version is also changed from per-user to be per-user-package),
compared to previously we needed this fingerprint to determine if we
need to call into PermissionController and let
RuntimePermissionsUpgradeController look at the latest numeric version
in its APK code.

But we still need the fingerprint for DefaultPermissionGrantPolicy
which is part of the platform, and it is currently missing in the new
subsystem, so this CL adds it to the new subsystem. Since
DefaultPermissionGrantPolicy only applies to what's on the system
image, we are also changing the fingerprint for it back to
Build.FINGERPRINT (instead of the extended fingerprint) when running
the new subsystem. Whereas for the old system, the fingerprint is
simply emulated to be either null or Build.FINGERPRINT depending on
whether the old subsystem wants to run DefaultPermissionGrantPolicy.

Bug: 284205103
Test: presubmit
Change-Id: Ib3358be57d7dd401fd2014ade3e58f9fc6c2b6a7