Work profile without password shouldn't be locked.

NB: there are two functions named setDeviceLockedForUser,
one that is called from refreshDeviceLockedForUser is NOT
changed in this CL.

Currently setDeviceLockedForUser is called for a work profile
with separate challenge in the following cases
1) with "true" when it gets locked (screen off or timeout) or
2) with "false" when the user solves work challenge

The 2nd case never happens if work challenge is empty,
since there is nothing to show to the user, so
mDeviceLockedForUser is set to "true" for the profile.
refreshDeviceLockedForUser funciton doesn't change values
for work profiles so it remains "true" forever. In addition
if the value is absent in the map, isDeviceLocked defaults
to "true". This way for those profiles it always returns
"true" to Quickstep/Overview which causes the bug.

This CL changes this behavior in two ways:

1) refreshDeviceLockedForUser now sets the value to "false"
for managed profiles that have separate but empty challenge.
This method is called early enough after reboot and for every
credential change, so it updates the value promptly.
2) setDeviceLocked for those profiles becomes no-op.

This way "false" is maintained in mDeviceLockedForUser.

For profiles with nonempty (both unified and separate)
challenge the behavior is unchanged.

Another probably more efficient approach would be to initialize
it to "false" for those profiles early enough and track whether
challenge becomes empty, but that seems more risky as it adds
new logic to boot phases and would require a call from
LockSettingsService or similar. This seems too risky at this point.

Test: manual, tried locking, unlocking, rebooting in all four
possible states and transitions between them:
1) Challenge can be separate or unified
2) Independently it can be empty or nonempty
Bug: 111838890
Change-Id: I189035ccd773b1cafed335bceff171a6c42b767f