Add support for custom MDL nodes

[krohmerNV]

The MDL generator is limited in a way that it only supported the mappings defined in the libraries/***lib/genmdl files.
With this pull request we now fully support nodes.
This comes in two flavors:

1. External .mdl file references:
   We allow to specify an MDL module located in an MDL search path using the file attribute. In combination with the function attribute a particular exported function can be selected. There is one aspect that needs to be considered when using this approach:

• Input and output names defined in MaterialX could conflict with reserved names in MDL. Therefore, we add a mxp_ prefix in case of such a conflict. The prefix is not applied in general because we want to be able to reference MDL modules without modifying them.

2. Inline MDL source code:
   By specifying the sourcecode attribute, MDL code can be added directly. The generator will inline this code into the generated MDL code, based on the interface of the corresponding node definition. Here, more aspects need to be considered:

• all input and input names defined in MaterialX are prefixed with mxp_ to keep things simple for authors that otherwise would need knowledge about the keywords in MDL.
• because the source code parsed from the MaterialX document contains no line breaks, we need to forbid comments using //. Instead the /* comment */ syntax can be used.
• to keep these inline source code nodes portable, it is not allowed to import additional MDL modules

Both variants support multiple outputs and for both variants tests have been added to illustrate and validate.
Additionally one more complex procedural material was added that makes use of the inline source code.

[krohmerNV]

@jstone-lucasfilm I believe this PR does not really add something new. It just allows to use standard MaterialX functionality provided by the node.

[jstone-lucasfilm]

This looks very promising, thanks @krohmerNV.

One concern that I have is the addition of language-specific examples to Materials/TestSuite, where previously all of our test suite examples have been language-independent. Since the introduction of that new pattern may take more design thought, I'm thinking that we may want to organize this contribution into two separate steps, where the first step introduces the new logic in MaterialXGenMdl that supports the usage of custom MDL nodes, and the second step is focused on a new design for our test suite that will accommodate language-specific tests.

What are your thoughts?

[krohmerNV]

That's a reasonable approach, yes.
Should I remove the test cases for now?

[jstone-lucasfilm]

@krohmerNV Sounds good!

[krohmerNV]

Should I remove the test cases for now?

done

[krohmerNV]

Thank you @jstone-lucasfilm for all the fixes!

[jstone-lucasfilm]

These changes look good to me, thanks @krohmerNV!