Partition weaver slots to avoid conflicts between the host image and GSI.

The device OS and an installed GSI will both attempt to write
authentication data to the same weaver slots. To prevent this, we can
use the /metadata partition (required for GSI support) to communicate
which slots are in use between OS images.

In this change, PasswordSlotManager stores a simple plain-text mapping in
/metadata/password_slots/slot_map using Java Properties.

Each key is an integer slot >= 0 and the value is either "host" or "gsi<N>",
where N is the index of the GSI. Currently only one GSI is allowed, so
this number is 1.

SyntheticPasswordManager always informs PasswordSlotManager of which slots
are actually in use, to avoid saving stale slot assignments. Stale
assignments won't happen from device wipes (since the GSI and /metadata
would be erased), but they are possible for deleted GSIs.
PasswordSlotManager is not informed of when a GSI is deleted (since the GSI
could be on, for example, an SD card), so any slots it was using are not
recycled until a fresh GSI is booted. This should not be a problem since
using more than 2-3 slots is rare.

If no /metadata partition is present, GSIs will not work, so in this
case PasswordSlotManager simply skips saving to disk.

Bug: 123716647
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/locksettings
Test: atest PasswordSlotManagerTests
Test: PIN unlocks device after booting into GSI
Change-Id: Ibcbd32d0085061fbfc0bb2ea1f3a605a104fabe3