Make ModelExperimental's bounding sphere update with model matrix

[j9liu]

Fixes #10074.

This PR fixes a bug where ModelExperimental's bounding sphere wouldn't be affected by changes in the model matrix. I added a unit test for it and observed that it worked in @lilleyse's sandcastle.

[cesium-concierge]

Thanks for the pull request @j9liu!

• ✔️ Signed CLA found.
• ❔ CHANGES.md was not updated.
  • If this change updates the public API in any way, please add a bullet point to CHANGES.md.

Reviewers, don't forget to make sure that:

• Cesium Viewer works.
• Works in 2D/CV.

[ptrgags]

@j9liu this PR does work as advertised. Though the bounding volume update code is spread out in several places, so we might want to review it holistically to see what if anything needs to be updated/simplified The model matrix and bounding sphere get updated in a few places:

• in buildDrawCommands.js I see that a bounding volume is computed from the render resources' copy, in-place. Does that make sense to do still? Note that sometimes buildDrawCommands() gets called a second time if draw commands need to be re-built (such as making a big change like swapping out a custom shader or style). Though since the whole pipeline gets re-run, this might be okay.
• I see that the bounding sphere gets updated in ModelMatrixUpdateStage -- we might need something similar for the final model bounding volume (like in the review comment below)

We can discuss this more on a call if needed since this is a little more nuanced than it first appears.

[j9liu]

@ptrgags - just wanted to clarify your buildDrawCommands.js comment. I see that the boundingSphere is transformed by the model matrix in place. Is the concern that if buildDrawCommands needs to get run again, the boundingSphere will get transformed by the model matrix twice?

[ptrgags]

@j9liu yes, that's what I meant, though now that I think about it, even when rebuildDrawCommands() gets run, the entire pipeline gets run, so the bounding sphere I believe would be created from scratch so I think it's okay.

[j9liu]

@ptrgags - got it. Is there anything else I should look at to wrap-up this PR?

[ptrgags]

@j9liu closer, though I noticed that the original code's _modelMatrix vs modelMatrix is a bit confusing, must have been missed in a past review. I left some notes of how to neaten that up.

[ptrgags]

@j9liu looks good now, I'll merge once CI passes!

[ptrgags]

thanks @j9liu!