Rationalize user_id foreign key

[jace]

Several tables have a user_id foreign key to the user table, representing at least three distinct concepts:

1. User as owner of this record
2. User as actor operating on this record (creator, editor)
3. User as subject of this record (typically a membership record; also for attribution as author/speaker/presenter)

These concepts should be separated:

1. Ownership is a shared concept between User and Organization, both of which are represented by the Account model (Profile before Rename Profile to Account #1519). All references to user_id in the context of ownership should be replaced with an account_id (or profile_id pending that change). Since the extant Profile model originally represented a username namespace, there are Users who have no profiles. This can no longer be allowed, and the new Account.name field will become nullable to accommodate users without usernames, or they will get auto-generated usernames. There is also the option of simply merging all three existing models (User, Organization, Profile) into a single Account model (see Rethink "organizations" #1489), since there is a separate problem of organizations being mis-registered as user accounts. Most models already use a profile_id column, with AuthClient as the sole exception, so this can temporarily be fixed by generating missing Profile records for AuthClient owners, leaving the heavy changes for a separate task.

2. A record of the user as an actor should use a column name that represents the action. This is already the case in membership models which have granted_by_id and revoked_by_id, and the action_by theme should be applied universally. In most existing cases, this will mean user_id being renamed to created_by_id.

3. When the user is a subject, the user_id name can be retained. The by name does not apply.

[jace]

All user_id columns have been renamed for #1519, with implementations in #1697 and later. The name account_id is now used solely to represent ownership. Attribution references use specific names like member_id (membership models), participant_id (registrations and tickets) and recipient_id (notifications). Actor references continue to use _by_id suffixes.