adding null checks for tweening

adding scale tween enumerator

modified port label scale
adding a check for using event in selectableMeshRender - may need to add this using logic to all my UI...
added an input window prefab and separated out the output window from the node view, now added under a separate child so node scale does not effect window scale.

The expanding input window is fairly buggy....

evaluation does not work currently as the output text window has moved in the hierarchy.

Next commit will fix this, by defining interfaces or classes for input and output between the node(or base) model/ view
create output display and pari types for bindings in UI

modify node model so that stored value is a dictionary of outport names to values

next commit will design a method for evaluating multi out nodes from python evaluator using port names...
progress made on multi outs, and connecting input to output, but implementation of port nickname dictionary is not working .... nicknames contain guids, which are not reasonable for variable output names in python block...
forcing addOutput port to have name

modified output display to destroy gameojbect containing each output display pair on re execution
defining new execution trigger ports and connector models and views
explicit execution is working at this point, unfortunately monodevelop again messed with line endings making it look like I changed many files.

core idea is to push delegates into python or any evaluation, these delegates just call the triggers on the nodes which in turn call further execution methods... I made an explicit activator evaluator that just grabs all nodes with no input execution triggers and calls them when the run button is pressed... to get observable execution need to call these delegates with generators.  I'd like to slow down execution so that one node executes per frame for now.

Other necessary next steps:
in the context of python, intermediate variables that we might use downstream are not available, for instance in example for loop :

for i in range(input1):
	calloutput(0)
	//use i to do something in another node downstream
calloutput(1)

i will not be available, to get this working will need to gather all outputs anytime any output trigger is called, this will update variable values just in time for any future use... in the simple case at least.

will need to consider if continuing to work on this implementation is worth the benefit -
attempting to use coroutines to control timing of execution per execution link
modified evaluation data structure to use a Queue, now output triggers do not call code directly but call a function that pushes another delegate Task object to the Q, then using information in the task object the stack will yield in the correct way and continue executing.  Will need to verify that code stays in sync between stack and code that is adding delegates/closures to Q.

also adding start execution node that requires no dependency.

still need to solve output intermediate variable issue, so that when each trigger is executed from the Q, the output variables are regathered from the python or other eval context.
adding input classes that read dictionary created per node type that exposes specific properties, this dictionary is used to create bindings between UI and node model by indexing into model with reflection.
fixing the input string value to jsonstring if the object is already a string, since then we end up adding extra quotation marks.
modify task and evaluation to data structure so that tasks are inserted behind their calling functions even if some other task is inserted before them.
modify the closure that is generated by triggering an output trigger, this now polls the evaluator scope for the current state of variables and stores them in a dictionary, this may not work with complex class variables and instead may need to implement a deep copy utility for all exposed types, for now seems to work with simple types.

This intermediate dictionary keeps track of all output variables values at the moment when the trigger is executed so that downstream nodes triggered from that point later by the scheduler have access to the correct values.  The model is set to this intermediate value at this time, this is almost like being able to set the node to an intermediate point in it's evaluation.

It's unclear how this will work with nodes that generate geometry or other objects into the unity scene scope, have to look into this....
modify input panel to use a simple regex for matching keywords - inserts tags, but deletes tags before adding more...
added a red markdown tag for operators