Initial interpretation/translation of SubtleCrypto interface into a
freedom-pgp api. Several tentative assumptions/design decisions
are throughout, a brief summary:

-The SubtleCrypto interface is fairly low level, allowing for
picking the crypto algorithm for each operation and other various
format-related arguments. I want to expose a much simpler api and
for now am simply omitting these parameters, with the assumption
that we will pick "good defaults" in our implementation/calls.

-It's a little unclear to me how SubtleCrypto envisions using
passphrases to protect keys (the word 'passphrase' appears
nowhere in the rather lengthy API specification). For now I am
assuming that we can hash/digest a passphrase and use it as a
wrapping key i.e. with the wrapKey/unwrapKey methods.

-I also definitely need to do some more work distinguishing
public and private keys. In SubtleCrypto there is KeyType and
KeyUsage: http://www.w3.org/TR/WebCryptoAPI/#key-interface-types
Right now I'm just treating all key parameters as string, but I
have added "_comment" fields to the json to annotate whether I
envision a particular method as acting on public or private keys.

And some general notes about SubtleCrypto, mostly for my own
references:
-It's fairly well documented (http://www.w3.org/TR/WebCryptoAPI/)
and on its way to being a standard, with development presence in
Chrome, IE11, and maybe a bit in Firefox (tracking bug at least).

-There's a WorkerCrypto interface for accessing SubtleCrypto
from within a WebWorker. However per a chat with Will this won't
help us as we need to support e.g. running in node and elsewhere,
and if anything may be worker property we'll need to remove.

-It has its critics (http://lwn.net/Articles/603769/), who are
mostly concerned with the low-levelness I described.

-Per the first two notes, it's bleeding edge and likely subject
to change, particularly around key management (import, wrap, etc.).
Further there may be inconsistent algorithm support across
implementations, which I think is all the more reason to hide that
from freedom API consumer (though it will complicate picking "good
defaults").

Related URLs:
http://www.w3.org/TR/WebCryptoAPI/#WorkerCrypto-interface
http://msdn.microsoft.com/en-us/library/ie/dn302325(v=vs.85).aspx
https://bugzilla.mozilla.org/show_bug.cgi?id=865789
Adding signEncrypt/decryptVerify to API, tweaks/attempts to register API
freedomkbpgp API registering successfully
Splitting demo from API, some initial implementation

This commit leaves a particular TODO that is blocking for kbpgp
in freedom - specifically, window.crypto/crypto.getRandomValues
needs to be visible from the WebWorker using kbpgp. Since these
are native code they are not normally visible in WebWorkers.

Suggested workaround: put crypto/getRandomValues in freedom core.
This will make the dependency asynchronous, but at least it should
be there. Once this is done, this repo can be revisited with an eye
to finishing out and testing the kbpgp -> API methods layer.
Merge pull request #1 from freedomjs/soycode-subtlecrypto

Soycode subtlecrypto