Proposal: remove explicit link functionality

[expede]

📖 Preview

A promised, this a proposed change to #1 that entirely removes the ability to add a CID to an embedded DAG.

I have only changed the schemata and example, but not the prose or FAQ. I'll fix those up once I confirm that this is aligned with y'all.

This PR doesn't bother with the hash, since we if the condiguration is the same as the currounding context can always calculate it directly from the data, and presumably we want to do that check anyway. If you want to be able to re-encode the outer DAG, then we can't provide a concrete CID anyways.

Evolvabilty

we could add later if we find that it's painful without it — much harder to remove it later than add it in later.

The ability to nest arbitrarily configured CIDs isn't in the main use case that I want this for, so please let me know if it's a bigger deal.

I ended up trying a version that's just "." as a key. The downside is that this has a might higher chance for a collision with someone else's (userland) schema. A nice thing about "/" is that conflicting on / is already a case that exists in DAG-JSON. The more fields or nesting that we add, the fewer cases we potentially overlap.

The PR as it stands leaves room for us to add the explicit link back over time without changing the format:

Otherwise, we could keep the nesting to maintain evolvability, which is closer to #1.

// Current PR
{
  "foo": 123,
  "bar": {".": {"some-inner": ["dag", "data"]}}, // Inner DAG
  "baz": "quux"
}

// Back to nesting
{
  "foo": 123,
  "bar": {"/": {".": {"some-inner": ["dag", "data"]}}} // Inner DAG
  "baz": "quux"
}

Which both leave open evolving to:

// This PR
{
  "foo": 123,
  "bar": {
    // Flat, with CID
    "/": bafyCid,
    ".": {"some-inner": ["dag", "data"]}
  },
  "baz": "quux"
}

// With nesting & CID
{
  "foo": 123,
  "bar": {
    "/": {
      "&": bafyCid,
      ".": {"some-inner": ["dag", "data"]}
    }
  },
  "baz": "quux"
}

These all of course "look" less like other codecs, but they can be easily transformed into DAG-CBOR, etc, which is the point.

I can live with either version, though. Lemme know.

[Gozala]

I'd personally prefer nested version so we don't have to reserve . along with /. That said I don't feel very strongly about it, so this version looks good to me as well.

[expede]

@Gozala I also prefer the nested version! I thought you were previously arguing for the opposite. Will update this PR