Rename NodeStyle to NodePrototype

[warpfork]

Like it says on the tin. Just rename the thing.

Both names for this comment had been in the running originally. I chose to roll with NodeStyle previously because it's just plain character-count shorter. But as time passed and more feedback is accumulated, NodePrototype appears to be the preferred.

Discussion with @hannahhoward preferred NodePrototype, with the only condition being that if it's confusable with prototypical inheritance concepts, that might be problematic. Acausally, @rvagg had also expressed a preference for NodePrototype, and as he's pretty deeply steeped in the javascript world, I'm going to take that as a pretty solid point that the potential confusion with prototypical inheritance is not a huge problem in this case.

We're currently tagged at v0.0.3 version; I'll probably make this change just before whatever becomes v0.0.4. It should be a "sed-refactor" (trivial find-and-replace) when it lands, so hopefully not too disruptive to downstreams.

---

Additionally: it may be worth noting that in the realm of schemas: we have a Type interface, which provides access to more info about a type. These will probably be the same as the Prototype for nodes that have them.

Or at least, conditionally.

If you have some foo.ipldsch and you do codegen with it: it'll emit a bunch of code and all those nodes will have a Type() method, and the value it returns will be pointer-equal to what the Style() Prototype() method returns.

If you have some foo.ipldsch and parse it and do runtime wrapper nodes to get the typed behaviors: they'll also have Type() and Style() Prototype() methods which return pointer-equal things.

And those values will also be content-wise equal to what you get from the codegen. But not pointer-equal.

It's hoped that the fact that the "type" and "prototype" are the same thing is reasonably comprehensible. Or at least, I hope it's more comprehensible than that the "type" and the "style" are the same thing. Alternate vocab for this is still open to discussion if someone has ideas that seem better.

[rvagg]

Dirty secret of the JavaScript world: a small portion of JS programmers fully understand the prototypical inheritance system, and that's why we got the class keyword eventually. Even though a class is just a shorthand for what you'd do with prototypes, it's way less confusing for most programmers so it now rules. They remain an obscure concept in CS even with JS's widespread adoption. You're safe with this one and I think it actually makes a ton of sense in this instance.

[warpfork]

This happened already! Closing.