Added uinames to ambiguously named nodes

[JGamache-autodesk]

I am trying to build UI names for a MaterialX node picker and had to create a hardcoded list of names to expand. Seeing this as not particularly good I wondered if uiname metadata could not be added at the source to add proper display names in cases where they could not be algorithmically generated.

This involves a few editorial decisions. I do not have any strong feelings about these and am open to iterate.

• UI names are title case. Seemed the best practice. Can be lowercased algorithmically if DCC prefers lower or sentence case as long as acronyms are preserved.
• Names that concatenate words together were split. Using the description in section comments if it sounded better.
• Names that were already split with "_" were left untouched. They can be title cased via code. 100% coverage might be better.
• Names that contained an acronym were processed to capitalize the acronym correctly. Especially useful for glTF and OpenPBR related nodes.
• Names that truncated some of the words were expanded (ifgreatereq, premult, etc).
• Well known truncated mathematical functions were not expanded (sin, cos, atan2, exp... probably the worst editorial decision of the bunch, but I plead "best practice" since this is how math is written in textbooks).

TODO: Fix this line in usdMtlx parser to try to find uiname metadata for the Label Sdr metadata.

[JGamache-autodesk]

There is an opportunity to add Hoffmann to the UI name. Same opportunities for Oren-Nayar and Sheen nodes upgraded for OpenPBR.

[JGamache-autodesk]

Singular to match with geomcolor and geompropvalue which were singular.

[ld-kerley]

I really like the idea of introducing consistent uiNames for the nodes - it will allow artists to more easily transition between DCCs without having to do any mental translation of what nodes do.

It did make me a little sad that this information has to be replicated on each <nodedef> element, and got me to wondering if we need an element that can hold information that relates to the whole node family in one place, to define things like uiName and possibly nodegroup on. Not something for this PR, but maybe something for us to think about.

[kwokcb]

@ld-kerley I like this idea of UI separation / reuse. Throwing out a possible syntax ui that can reference interface elements: nodedefs and compound nodegraphs:

  <!-- Associate with a nodedef interface -->
  <ui name="UI_def_name" uiname="My UI Name" nodedef="ND_def_name" >
    <input name="in1" uigroup="group1" uiname="Input 1" doc="This is the first input" />
    <input name="in2" uigroup="group2" uiname="Input 2" doc="This is the second input" />
    <output name="out1" uigroup="group2" uiname="Output 2" doc="This is the first output" />  
  </ui>

  <!-- Associate with a compound graph interface -->
  <ui name="UI_graph_name" uiname="My UI Graph Name" nodegraph="my graph" >
    <input name="in1" uigroup="group1" uiname="Input 1" doc="This is the first graph input" />
    <input name="in2" uigroup="group2" uiname="Input 2" doc="This is the second graph input" />
    <output name="out1" uigroup="group2" uiname="Output 2" doc="This is the first graph output" />  
  </ui>

Can take this thread outside this PR but thought I'd drop this in as if you want a consistent naming you might also want to consider consistency for input / output names as well.