Add stage scaling from configured scale values.

[aclegg3]

Motivation and Context

TL;DR: allows scaling set in the stage configs to propagate through to render and collision assets.

Context:

• We have allowed non-uniform (3D) scale vectors to be configured for object and stage configs (doc page) for some time.
• However, the stage loading pathway has not used these values during construction of the render and collision objects.
• This PR simply queries existing configured scale when constructing the render instance and collision shapes for the stage asset.

NOTE: this is not tested for split semantic assets. It may require some additional implementation for split semantic scene graphs like HM3D, scannet, MP3D, etc... For context: this is because we load an additional asset into an additional SceneGraph for such assets. The scale should be pulled and set there as well.

How Has This Been Tested

Locally in viewer. Should be CI tested.

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have completed my CLA (see CONTRIBUTING)
• I have added tests to cover my changes.
• All new and existing tests passed.

[jturner65]

We revisited this 2 years ago, and were going to investigate why it had not been implemented already. I thought at the time that there was a specific reason that we had discussed back when I was implementing the scene instantiation even earlier, on the old slack, but I wasn't able to access the old slack at the time. I'm going to investigate this a bit to see if I can find what the reason is (I have all our old conversations from that slack, so I'll look real quick)

I'll approve this too, and if there's a good reason not to have this somehow, we can revisit it later.