Fix Settings writes to a different user

Oops.  Stacked bugs:  first, the desired user handle was not properly
being passed from the call() entry point to the database operations;
then on top of that, the client-side cache management was still
looking in the local user's cache for the data, so a request to read
a different user's settings would return the local user's instead if
that key was already known to the local user's cache.

Reads and writes of a different user's settings are now uncached,
so they're relatively much slower.  They're rare, however, so this
is not something to worry about unless we encounter a real world
case where it's a significant factor.

This CL also adds a bit of cross-user settings read/write testing
to the existing provider suite.  These new tests caught both the
known wrong-user-write bug and discovered the client-side cache
bug, so yay.

Finally, the existing wholesale mutual-exclusion approach would
deadlock in certain circumstances due to the fact that the
settings database creation code might have to call out to the
Package Manager while populating the bookmark/shortcut table,
and the Package Manager would then call back into the settings
provider in the course of handling that request.  The synchronization
regime has been significantly tightened up now: now the database
code [which is known to deal with concurrency itself] is allowed
to cope with multiple parallel openers of the same db; this
allows the settings provider to avoid calling out to other parts
of the system even implicitly while its internal lock is held.

Change-Id: Ib77d445b4a2ec658cc5c210830f6977c981f87ed