Split ports into input/output

[McManning]

Big (backwards breaking) refactor so not sure if it makes sense to do:

Currently ports are stored in a single array on AbstractNode and methods more or less assume one array (AddPort, RemovePort, GetPort). Ports themselves know whether or not they're input or output (Port.isInput) which then changes the behavior of methods like GetValue.

From an optimization standpoint, it doesn't really matter if we're going through a list of 6 ports vs 3 ports to find the right named output. But from a usability standpoint - there's implicit gotchas in the API. E.g. you can't have an output port named the same as an input port, and the behavior of Port.GetValue changing dramatically based on that isInput flag.

I think I'm going to make a branch with the change, see what it looks like, and whether or not it makes more sense to do it that way than what I've got currently.

[McManning]

Couple other thoughts in no particular order:

• If I were to split it out, I'd be able to create explicit InputPort and OutputPort classes - without worrying about Unity polymorphic list serialization headaches
• If I wanted to extend in the future into different port directions (e.g. Direction.Down, Direction.Up, Direction.ExecutionFlow or whatever actually makes sense for particular use cases), I'd have to make an explicit collection and methods per new direction. Whereas right now it's a simple AddPort(new Port(configured however I want)) and GetPort("Foo")
• While it's kinda awkward that IO can't have the same name, maybe that'd help reduce debugging confusion later?

[McManning]

For the storage format in runtime nodes, I'm going to keep this as a single list. Moving forward - I might look at changing the API to be more explicit, but since that won't be a breaking change on the format itself I'm moving this off the priority list for release.

[McManning]

Closing this out - I'm sticking with a single port list until it becomes a problem. At which point I can look at doing a 2.0 for it.