MaterialX cannot find NodeDef for `separate3` type

Hi,

I meandered around the point in [this discussion](https://github.com/Autodesk/maya-usd/discussions/2710) because I was finding my way, but I've managed to narrow down the cause and can give instructions on how to recreate the issue.

Certain MaterialX nodes will throw the following error...

`// Error: Failed verification: ' nodeDef ' -- Could not find MaterialX NodeDef for Node 'NG_Maya/N5'. Please recheck library paths. // `

`// Error: Caught exception 'Could not find a nodedef for node 'N5'' while processing /Proxy_torus_capShape_00000175CB3F4E70/example/mat/dg_test' // `

And it fails to draw correctly in the standard Viewport 2.0, showing instead a simple Grey shader.

Checking the MaterialX shader built with TF_DEBUG set to "HDVP2_DEBUG_MATERIAL" suggests that this is caused by whatever node is using the output from a `separate3` node as an input. It may not be all `separate3` nodes (though so far it seems to affect at least `NG_separate3_vector3` and `NG_separate3_color3`) and may affect more than just these. I can confirm that `NG_separate3_vector3` _is_ found within `..\mayausd\USD3\libraries\stdlib\stdlib_defs.mtlx`.

Attached is `torus_cap.usda` file to test - it's got a very simple Material and embedded geo.

**Steps to reproduce**

I've re-created the problem on Maya 2022.4 with maya_usd-0.20.0 and Maya 2023.2 with maya_usd-0.19.0, both on my studio workstation and my home workstation.

Steps to reproduce the behavior:

1. Open an empty Maya scene, open the USD Layer Editor.
2. Create -> Stage From File -> Navigate to torus_cap.usda -> Open
3. Enable 'Textured' in the Viewport
4. Check Script Output for the error. Also check the Output window to see which node is being referenced - though, again, it's the node going _into_ the listed node that causes the problem.

To demonstrate this last point, my example .usda has two `combine3` Shaders, one going into the `base_color` input and one going into the `transmission_color` input. The one going into `base_color` (named `mtlx_combine_from_separate` is, well, the one coming from the `separate3` shader node) and this is what causes the problem. If you edit the .usda file so that both color inputs are the same that was originally just going into the `transmission_color` (eschewing the `separate3` in favour of simply starting with 3 floats in the first place, combined in `mtlx_combine_from_floats`) you should find that it doesn't error and does show up nicely in the viewport. I've saved a copy of this amended version called `torus_cap_from_floats.usda` and attached it.

**Expected behavior**
No errors are displayed and it displays in the viewport correctly. `torus_cap_from_floats.usda` demonstrates how I would expect it to work.

**Attachments**
If applicable, add screenshots, sample files, etc to help explain your problem.

All tests are on Windows 10 or 11, all using the released binaries (not built myself).

Maya 2022.4, maya_usd-0.20.0 (tested both the released version on here and via the Autodesk updater app thingy.
Maya 2023.2, maya_usd-0.19.0 that ships with the 2023.2 installer.

**Additional context**
On Maya 2022 I'm still getting all sorts of UI errors when viewing the Extra Attributes which you can avoid by setting `cmds.optionVar(iv=("attrEditorIsLongName", 0))`. However I've concluded this is unrelated because I don't get this EA issue on 2023.2 yet the actual problem described above persists.

[torus_cap.usda.txt](https://github.com/Autodesk/maya-usd/files/9992635/torus_cap.usda.txt)
[torus_cap_from_floats.usda.txt](https://github.com/Autodesk/maya-usd/files/9992636/torus_cap_from_floats.usda.txt)