Returning Sockets not Nodes

Discussed a bit in the description of #75, we could return the output socket of simple math nodes instead of the full node as the socket will likely be all the user is after. Current the result of this is a `VectorMath` node. This aligns with the current "node-first" approach, but can be a bit inconvenient. It makes sense that the result of it would be a vector, but to do anything I first need to access to the output `VectorSocket`. ```py result = g.Vector() * g.Vector() for axis in result.o.vector: axis + 1.0 result.o.vector.x + 1.0 ``` It might make sense that instead if the result of the operation was the resulting output `VectorSocket` that we could iterate with it more quickly. ```py result = g.Vector() * g.Vector() for axis in result: axis + 1.0 axis.x + 1.0 ``` If we do this approach, everything becomes a bit less obvious _what is what_. We have quite a robust typing system so type-hinting helps a lot which explaining what is going on, but we might then want to start returning the socket for simple input nodes like `Position`: ```py pos = g.Position().o.position # old pos = g.Position() # new, already returns the socket ``` This only gets confusing where there are "simple" input nodes which contain multiple sockets such as `Normal` which outputs both `normal` and `true_normal`. It wouldn't be obvious what is being returned when. I think at least for creating nodes it still makes sense to _always_ return the node, but there might instead be a helper method which creates the node and returns the socket. ```py pos = g.position() # returns the position socket? pos = g.input.position() # returns the position socket? ``` I think that style-wise if we just let users define their parameters at the start with then they have control and it's obvious what is what. Doesn't answer the question around what to return for the math / comparison operations though. ```py pos = g.Position().pos norm = g.Normal().true_normal ... # rest of script ```