Fixed crash when loading glTF's KHR_texture_transform without a sample

[ProjectBarks]

Cesium's implementation of the KHR_texture_transform extension of glTF makes poor assumptions that the optional sampler will be defined.

Sandcastle used for testing.

In response to: #7916

[cesium-concierge]

Thanks for the pull request @ProjectBarks!

• ✔️ Signed CLA found.
• ❔ Unit tests were not updated.
  • Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

• Cesium Viewer works.
• Works in 2D/CV.
• Works (or fails gracefully) in IE11.

[mramato]

We should add a unit test for this.

@emackey do you want to take a look at this (or have any suggestions for the simplest way @ProjectBarks can add a test for this case)?

[mramato]

Also, thanks @ProjectBarks!

[ProjectBarks]

Great suggestions Matt. I did some performance comparisons offline and this was the best design performance wise.

[emackey]

Hi guys. While trying to review this, I started to wonder why the texture transform code is concerned about the repeat enums at all, and why it would take a choice-of-three enum and convert it to a Boolean. Turns out, this code doesn't need to be dealing with that repeat setting or looking up the sampler at all. Model.js configures WebGL itself with that enum, we don't need to replicate it in fragment shader math.

I think I'll open a separate PR for this, and completely remove the repeat logic.

[mramato]

Thanks @emackey we'll leave this open until your PR is merged (in which case this should auto close).