OStatus/ensureProfile tweaks

How it works now
If you need to get an OStatus-able profile reference for a remote user, you call one of these functions:


 * Ostatus_profile::ensureProfileURL('http://example.com/user') or...
 * Ostatus_profile::ensureWebfinger('user@example.com'):

('ensure' in our parlance means that when we return successfully, you've definitely got an entry in the DB to work with, whether or not it was already recorded before.)

If discovery succeeds, we save local user/group profile data and an ostatus_profile entry, which is returned to caller.

If discovery fails, an exception is thrown.

What's good with this
The good thing is that now that we've done the discovery, we've saved the data locally and don't have to do as much work next time we reference that remote user.

What's bad with this
The downside is that we end up saving profile/group/ostatus_profile entries in the DB, and an avatar on the filesystem, even if we never actually touch that user again. Not too bad for user-initiated 'remote subscribe' that gets canceled, but if we're pulling a list of thousands of remote 'friends' of whom two get subscribed, that might be a bit silly.

We have no garbage collection for unused profile references.

Suggestion
It could be useful to separate the discovery and save steps, so when we need to get info but don't actually need to save it to the database we can use that:


 * OStatusPlugin::discoverProfileURL('http://example.com/user')
 * OStatusPlugin::discoverWebfinger('user@example.com')

The main problem is that most of the interesting stuff like the person's name, avatar reference, etc are not stored in an ostatus_profile record, but rather in the general profile, group, and avatar tables. So if we returned a non-saved ostatus_profile object, you would not be able to follow through to a live profile object.

Possibilities:
 * 1) Return a mock object with the same interfaces, but not pulling from the database
 * 2) * problem: extra code maintenance
 * 3) * problem: unexpected behavior likely if we pass the objects around wrong; we don't have very clean interfaces
 * 4) Have these calls return arrays with a dictionary of information, instead of a raw object.
 * 5) * If we have an existing record, we can fill the dictionary with data from the ostatus_profile/profile/group/avatar records.
 * 6) * good: this might actually be quite handy to use within the ensure functions, letting us do all the discovery with a simple data set and then saving it into the DB objects.
 * 7) * good: no confusion between live objects and mock objects -- it's distinct.