Store extended contribution details in a separate IPFS document

[raucao]

As discussed during the last weekly call, we should extract the extended contribution details from the main contribution document and store them in a separate document, which can be side-loaded only when necessary. At the moment, no client actually needs the extended details at all, and in kredits-web, we will only need them when looking at a specific contribution.

Reasoning

Consider a typical GitHub pull request document: https://ipfs.io/ipfs/Qmbd62E98ikysm2vzgj89w1b4QutdWP1oN6YFjLqphyL7D

The size of this is ~19KB. However, the only necessary information for most clients is:

{
  "@context": "https://schema.kosmos.org",
  "@type": "Contribution",
  "contributor": {
    "ipfs": "QmbZhFsoANaGAWCV3pcpYKiGLEyJKbFcgD8ynhCWp93YBk"
  },
  "date": "2019-07-15",
  "time": "16:54:56Z",
  "kind": "dev",
  "description": "67P/kredits-web: Use ember-auto-import instead of ember-browserify"
}

A cool 309 bytes in this case, which is ~1.6% of the current document.

So the idea is to do the same as with the contributor hash (which isn't currently used by any client actually, but that's irrelevant here):

{
  "@context": "https://schema.kosmos.org",
  "@type": "Contribution",
  "contributor": {
    "ipfs": "QmbZhFsoANaGAWCV3pcpYKiGLEyJKbFcgD8ynhCWp93YBk"
  },
  "date": "2019-07-15",
  "time": "16:54:56Z",
  "kind": "dev",
  "description": "67P/kredits-web: Use ember-auto-import instead of ember-browserify",
  "details": {
    "ipfs": "QmbZhFsoANaGAWCV3pcpYKiGLEyJKbjnskjdnscnKJDSNVK"
  }
}

Pinning / backup / distribution

I would propose to then also extend the ipfs-pinner to recognize any generic JSON objects with a "ipfs" property and pin those hashes automatically as well.

[raucao]

@fsmanuel Interested in taking a stab at this perhaps?