Retrofit fallback data to users that don't have it, etc.

Fallback data comprises fallbackProxyUserId and newly created field
fallbackProxy.  The latter will be used to get the installerLocation
for update emails.

Also initialize this data on user creation.

Since it was simpler to do the refactoring than to dig deeper in the
hole of the shouldSendInvite/prepareForSending scheme, which was not
really working anyway (we had no way to retry sending invites), I
moved the actual sending of invites to a TaskQueue task.

Tests performed prior to committing this:

    Check that invite e-mails get sent at all with the TaskQueued flow. OK
    Check that a newly invited user gets the fallbackProxyUserId and fallbackProxy set. OK
    Check that fallbackProxyUserId and fallbackProxy get overridden on XMPP Available presences. OK
        But for fallback users, only the fallbackProxy. OK
        Check that authorized invites that were held because of lack of fallbackProxyUserId get sent as a result of this. OK
    Check that fallbackProxyUserId and fallbackProxy get initialized (but not overriden) when running the update job. OK
        Same caveats as above. OK