Add utility function to fix connection type mismatches

[kwokcb]

Context

It is possible for documents to contain connections between mismatched types.
This is not considered to valid based on the MaterialX specification and is caught by validation.

Premise

MaterialX should provide core support to "patch" these mismatched type connections.
The proposal is to add in explicit convert nodes as appropriate noting some conversions
do no make sense since they cannot be type converted.

Work

Part Ia : Core Logic

• Add a new utility function to find type mismatches. e.g. addExplicitTypeConversions() or
  something better :).
• Consider the existing convert nodes as the set of available supported types. Fail / skip
  if not supported.
• Otherwise insert the appropriate convert node between the existing connection. e.g
  if there is a vector3 output connected to a color3 input, then create a convert node which
  handles vector3 to colore conversion and insert it between the existing connection.
• It would be useful as feedback to return the list of nodes added w.r.t. the connection, and
  a list of connections which cannot be handled.

Note: There is overlap with the existing validate() logic which already performs detection.
It would be desirable to reuse calling into that logic, or refactor to create a separate reusable detection
function.

Part Ib: Test

• Add in some test cases that perform validation, fix, and re-validation to make sure it
  works. This can be in C++ as part of unit tests.
• This is a composite of possible connection configurations to test:
  • node -> node connections
  • input interface -> node connections -> + output interface
  • upstream nodes with single / multiple connections ("multioutput")
  • node -> input interface connections
  • output interface -> node connections
  • nesting of GraphElements : Currently only NodeGraphs under a Document
  • fan out from upstream outputs to more than 1 input downstream input.

Part II: API

• Add Python and Javascript bindings.

Part III : API command

• Add in a sample command to perform type connection fixes.

---

If this is a single day dev-days project then Part I could be considered an initial task.

[christopher-jacobs]

I would like to take a look at this issue for the upcoming Dev Days! If it's alright, I might start working on it today so that I can have a better chance of submitting a PR Thursday.

[jstone-lucasfilm]

Thanks @christopher-jacobs, and I have assigned it to you!

[kwokcb]

Additional clarification points:

1. You can have "interface" inputs (input nodes) connected to internal node inputs.
2. You have have internal node outputs connected to interface "outputs" (output nodes).

The general "get" / "set" connected node APIs will probably not work in these cases as they are not stricty node-node connections and also they will traverse to the parent.

3. You need to consider not just NodeGraphs but "graphs" in general which is the parent class GraphElement. This will allow include of Documents which inherit from GraphElement.

As such you can start from the top level Document or any child GraphElement. At the Document level, I think children should be traversed first and then Document level as the child traversal can change the top level contents.