Reducing attack surface of local client's proof verification code

As the list of proof types grows (see https://github.com/keybase/keybase-issues/issues/518) the keybase client will have an increasing quantity of code that goes out to the network, has an interaction, pulls down data, and inspects it. Code that handles untrusted data has a reputation for security holes, so as the quantity of this code grows, there should be some effort to isolate it from the rest of the application.

For the moment most or all of the proof verifications involve grabbing a file over HTTP and parsing out a proof, then inspecting the proof, which means the risk is mostly shared between the proof types. However, other types of proofs (e.g. blockchain proofs, such as Ethereum contracts) would require new code.

A large part of this issue is simply the question: How many _types_ of proof are we likely to see?

(See https://github.com/keybase/keybase-issues/issues/518#issuecomment-242433478 for the ill-placed discussion I inadvertently started on this topic -- some relevant chunks there.)

Start by reading issue #518 and the linked comment, then inventory the existing proof verification paths described here, including HTTP fetching and parsing. The issue does not name files, tests, an isolation design, or a concrete completion condition, so the scope and definition of done need to be established first.

Written by the indexing model from the issue text.