Separate profiles/keyserver and accounts/webGPG

Keybase has two clusters of features.

**Profiles** display folks' keys and info about them, as well as linking to signed statements that they control particular social media accounts. Their function is to display and communicate information, not to be heavily interactive. This cluster of functionality is a lot like a traditional SKS keyserver, except from the present, not the nineties.

**Accounts** allow folks to _do_ a bunch of neat stuff with GPG. One can upload a hopefully-client-encrypted key, use it through a web interface, send and receive messages and whatnot. This is a whole bunch of interactive functionality, which we might expect to have total feature parity with the command line client.

---

Suggestion: completely separate these features.

Make the **profiles** functionality completely key-based, without any user accounts needed. If someone uses the CLI client, they should be able to generate a key and all the ancillary info for their profile, and upload it. Keybase should verify signatures, and display valid information based purely on the authenticity of the key. This would make the profile functionality of keybase possible to federable (#162), and protects Keybase from being a sole authority and single point of failure. Keybase could even sync with SKS keyservers behind the scenes, and only display keys which had data packets containing Keybase-specific info like proofs.

The **accounts** functionality then becomes an independent web- (or browser-add-on) GPG client. It has all the interactive features currently planned, like sending and receiving messages, or generating and verifying proofs. It's a full client for the Keybase profile system. In fact, a user might not even realize that these two services are separate, because the Keybase web client automatically generates keys with Keybase-profile information attached and uploads them to the profile service. The CLI client has the same features, but allows users to operate from their own machines. Not all the CLI functionality necessarily needs a Keybase user account.

The issue names no files, tests, or entry points; begin by mapping the current profile and account functionality in the Keybase client and website. Done would require an agreed design that separates key-based profiles from interactive accounts, including their interfaces and responsibilities.

Written by the indexing model from the issue text.