Do not reject 'velocities' or 'accelerations' as primvars for the renderer

[robp-sidefx]

Description of Change(s)

Selectively undoing part of https://github.com/PixarAnimationStudios/OpenUSD/commit/c55f1384b37ffd74fac58b6a18ec33b2699b4687#diff-4058391680f6b738982c851862d178868840850626cbaa3ad17c597b6c21014f to restore velocities and accelerations as valid primvars for the renderer.

Fixes Issue(s)

#3508

Checklist

[X] I have created this PR based on the dev branch

[X] I have followed the coding conventions

[ ] I have added unit tests that exercise this functionality (Reference: testing guidelines)

[ ] I have verified that all unit tests pass with the proposed changes

[X] I have submitted a signed Contributor License Agreement (Reference: Contributor License Agreement instructions)

[jesschimein]

Filed as internal issue #USD-10624

(This is an automated message. See here for more information.)

[jesschimein]

/AzurePipelines run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 1 pipeline(s).

[unhyperbolic]

"velocities" instead of "primvars:velocities" should still work.

Did the UsdImaging Delegate actually take "primvars:velocities" for a point instancer? I am looking at UsdImagingPointInstancerAdapter::Get and I don't see that it does.

[robp-sidefx]

"velocities" instead of "primvars:velocities" should still work.

To clarify, the issue (as it shows up as a problem for us) in https://github.com/PixarAnimationStudios/OpenUSD/issues/3508 is that the primvar is being blocked when specified on an Xform. Specifying "velocities" as an attribute on an Xform also, as best I can tell, doesn't flow through Hydra.

Feedback from @spiffmon on the issue suggested reluctance to revert this, so we'll likely proceed with Houdini-specific primvar naming to achieve our desired workflow.