Rename Profile to Account

[jace]

The "Profile" model represents an internal name for the "profile page" of a user or organization, but this is not a suitable user-facing product term. The term "Account" is more suitable, and represents a cohesive concept for what are currently distinct internal concepts. These tasks can be handled separately from each other:

1. [x] Profile model to be renamed to Account model, with profile_id columns renamed to account_id
2. [x] AccountView to be renamed to UserAccountSettingsView
3. [x] Search results should use the term "Accounts" instead of "Profiles". ~This is currently the only public-facing acknowledgement of the "profile" term~ (wow, no!) (#1524)
4. [x] Replace hyphens with underscores in usernames, and provide remapping when a URL has a hyphen (via a custom comparator for Profile.name/Account.name) (also as #1076)

The Profile/Account model remains optional for users without usernames, and that decision should be made separately, perhaps in #1489, where there is a related recurring problem with organizations being registered as user accounts.

[jace]

This has emerged into a larger ticket: merge all of User, Organization, Profile and AuthClient into a single model named Account, retaining an identification column to distinguish between user, org and client.

The rationale is that these three types all share the concept of ownership of resources and need a common model for foreign key constraints. The Profile model has been used for this, overloading its original usecase of containing a username namespace shared between user and org. However, users without usernames don't have a linked profile, excluding them from ownership, and auth clients don't have a profile either. For a while there was the idea of allowing Profile's name field to be nullable, to extend coverage to all users.

The join queries have always been a pain. Merging them into a single table will simplify both ownership as a concept, and the SQL queries to load any of them. The app layer can continue to use the type identification column to apply constraints on who can do what.

However, this merger could be fairly painful to complete simply for the sheer range of references to these models.

[jace]

AuthClient may not be in this merger, at least in the first round. The intent is to recognise a bot account as a distinct account type, but bots are distinct from auth clients, as auth clients operate on behalf of a regular user account. We'll tackle bot accounts later.