Further fixes to Managed_DataObject::_allCacheKeys(): now uses self::multicacheKey...

Further fixes to Managed_DataObject::_allCacheKeys(): now uses self::multicacheKey() to generate the (possibly compound) keys, which makes it match the order of the keys used when calling pkeyGet().

This should resolve the issues darkip was reporting with user_im_prefs entries returning null immediately after insertion (seen with memcached off, so it was happening even with the built-in in-process cache in the Cache base class).

What was happening was that the initial pkeyGet() would end up saving a negative cache entry under the form with the fields sorted in the key, as via multicacheKey():

    'statusnet:blaguette:user_im_prefs:screenname,transport:brionv,sms' => 'N;'

then we'd do an insert() on the new entry, saving cache entries for the non-sorted key names returned by _allCacheKeys():

    'statusnet:blaguette:user_im_prefs:transport,screenname:sms,brionv' => 'O...'
    'statusnet:blaguette:user_im_prefs:user_id,transport:1234,sms' => 'O...'

but the next query via pkeyGet() still saw the negative lookup cache from before, and came back with null.

Now, _allCacheKeys() sorts the fields in the keys by using the same key-builder function, and queries pick up the same thing you just inserted. :)