Rename methods for unlocking, locking, and protecting CE storage

Users have many cryptographic keys, such as:

- Storage (file-based encryption) keys, both CE and DE
- Keystore super keys, both AfterFirstUnlock and UnlockedDeviceRequired
- Keystore client keys
- Synthetic password and the Keystore key that encrypts it

Unfortunately, many StorageManager, vold, and LockSettingsService
methods refer simply to "UserKey".  It isn't clear or consistent which
key(s) they mean.  For example, unlockUserKey unlocks CE storage,
createUserKey creates both the CE and DE keys, and
unlockUserKeyIfUnsecured unlocks CE storage but also does other things.
With the planned fixes to handle Keystore super keys more similarly to
the CE storage key (b/296464083), this confusion will increase further.

This CL is the first part of fixing this.  It renames the following
StorageManager methods to make it clear that they deal with CE storage:

   unlockUserKey => unlockCeStorage
   lockUserKey => lockCeStorage
   setUserKeyProtection => setCeStorageProtection

In addition, it starts the renaming of:

   isUserKeyUnlocked => isCeStorageUnlocked

However, isUserKeyUnlocked is used more widely and is also a @TestApi,
so for now it still exists alongside the new name.  Later CLs will
convert the remaining callers of isUserKeyUnlocked to use the new name.

No change in behavior except for some changed log messages.

Bug: 306204742
Flag: exempt, mechanical refactoring
Test: presubmit
Change-Id: I202ebbfd2b4f79fedb3ed120a8ad81500c126894