feat: return cid of last node traversed from ipld.get and friends

[achingbrain]

We can pass a path to ipld.get that makes the resolver attempt to do a graph traversal until it runs out of path segments to resolve.

At that point we don't know the cid of the node that will be returned, which things like the unixfs-exporter need to know.

[codecov]

Codecov Report

Merging #181 into master will increase coverage by 0.03%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #181      +/-   ##
==========================================
+ Coverage    93.4%   93.43%   +0.03%     
==========================================
  Files           1        1              
  Lines         197      198       +1     
==========================================
+ Hits          184      185       +1     
  Misses         13       13

Impacted Files	Coverage Δ
src/index.js	93.43% <100%> (+0.03%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 62b0bf2...b9aabea. Read the comment docs.

[vmx]

Can you please update the README and add another test for the case when there is a remainderPath?

[vmx]

Adding a check for the cid to an existing test is good enough.

[achingbrain]

@vmx Done. I *think* I'm returning the right CID. That is, if my nodes are:

// node1, cid1
{
  links: [
    cid2
  ]
}

// node2, cid2
{
  links: [
  ]
}

Then this sort of thing happens:

ipld.get(cid1, 'Links/0/Hash/Links/1/Data', (err, res) => {
  // res.remainderPath === 'Links/1/Data'
  // res.cid === cid2  <- because I could not resolve 'Links/1/Data' inside node2
})

Does that look right?

[vmx]

@achingbrain It looks right. Perhaps we can make it clearer in the README. It is the CID where the remainderPath has its root, right?

[achingbrain]

That's a good way of putting it, have updated the README again.