Node versioning

[Keavon]

Create an overrides/versioning system that lets users override document nodes (subgraphs), either overriding part of the subgraph or creating a copy of the full document node; then make a way of tracking versions and upgrading old documents to new versions

[0HyperCube]

This sounds overly complex @Keavon. Could we think about having a system whereby there is only one version of each node for increased simplicity? For example blender doesn't allow users to have different versions of the same node.

[Keavon]

We need some way to let us upgrade nodes without breaking user documents which depend on its proto node and/or document node's network. One situation is when the "signature" of the node changes, and we could induce an upgrade (that's what Blender does). The other situation is when the algorithm itself changes, in which case we need to potentially mark the node as deprecated but still reference the old implementation (particularly its proto node that we'd archive), so as to ensure that users can open documents in the future without the rendered output changing.

This relates to #1609 and the node marketplace, which would essentially be our ecosystem's package manager for both first-party (included out-of-the-box) and third-party nodes. We, and third parties, will need the ability to publish updated nodes (probably using semver). This issue essentially talks about that aspect of the package manager system we'll be building, but potentially an early form of just the versioning system in what will become the full package manager.

Please let me know if you have any questions about that.