Improve docs for AssignNode; and datamodel.Copy function.

[warpfork]

Revisited the docs on the NodeAssembler interface, and described AssignNode's contract and purpose better.

Also created a datamodel.Copy function. This is related because just having that code gave me something to refer to which helped further clarify AssignNode. (We should also probably start calling this function from codegen output, and perhaps other places, where similar logic is currently probably repeated, but I've left that out of this diff for now.)

[rvagg]

I'm wondering about the implications of just having a shallow Copy. How are users going to use this, what are their expectations, and what is the potential for mismatch between expectations and reality when it comes to just doing a shallow? Same goes for AssignNode too I suppose since the same set of concerns apply there too, no?

[warpfork]

Yeah: we just have to try to solve that with docs docs docs, I think. These are my first try, but maybe you can prose it even better.

We could also name this function ShallowCopy, if that makes anything better?

Fwiw, I don't think I'd be entirely surprised if we also someday want to have some kind of DumbCopy function which explicitly doesn't ever dip back into AssignNode, and does all the recursion itself. But it's a little hard to defend that without saying "this is for working with node implementations that have broken contracts", so I'm on the fence about it.

[warpfork]

Will probably motion to merge this if no objections.

I'm always open to the docs getting even better in future edits, but I think this is better than where we started.

[smrz2001]

Did have a quick question here @warpfork. For being able to leverage the Copy method in the go-dag-jose code, I am currently pointing to your branch. Would you recommend keeping it that way till an IPLD release is available, or just waiting for the new release and using it then (assuming it's not going to be a long while), or copying your code (with attribution) until the code is released and switching to it then?

[warpfork]

It's always safe to refer to a commit hash by the time it lands on master. In this case, I'm also happy to refrain from rebases and use a merge commit when landing this, if you're already referring to these hashes.

(There's some notes about this policy in HACKME_mergeStrategy.md :))

[smrz2001]

It's always safe to refer to a commit hash by the time it lands on master. In this case, I'm also happy to refrain from rebases and use a merge commit when landing this, if you're already referring to these hashes.

(There's some notes about this policy in HACKME_mergeStrategy.md :))

Oh, it's no worry! My PR is still in progress so I can certainly wait till your PR is merged and update the hash.

Will keep that document in mind for the future 👍🏼