Add SampleHeightMostDetailed tileset load failure test

[kring]

No description provided.

[j9liu]

Thanks @kring ! I confirmed that the changes result in the future completing and an exception being thrown.

I noticed a slight difference in behavior between this and CesiumGS/cesium-unreal#1526. In Unreal, during the std::move(future).catchImmediately call, we initialize the result even when the promise fails. So it's possible to iterate over that array of falses and do something like print a string. But accessing task.Result causes the rest of the script to stop working due to an exception.

I can catch it of course, and save the rest of the application, but was wondering if this behavior is built into the way C# Tasks work? Or if it was worth achieving symmetry with Unreal, if possible. Not a big concern though, this can be merged otherwise.

[kring]

Hmm this is interesting. So in cesium-native, if the tileset can't be sampled at all, we reject the future. Unity tasks have a similar mechanism to future rejection, so that's what we do there, too.

But in Unreal, all we have is an OnHeightsSampled callback, there's no separate error pathway. So instead we call that OnHeightsSampled and indicate that every height failed to sample. As I was doing this, I actually thought that Unreal was the compromise.

I can kind of argue either way, though. The question is: when the tileset is completely broken, and so no height samples will ever succeed, should we report this is "every height sample failed", or should we report it as a more dramatic error? Given that the latter is not possible in Unreal (short of making the user supply a separate error callback), maybe there's value in consistency across game engines.

[kring]

The more I think about it, the more I like the idea that there's just one error mechanism, rather than two. So I'll switch Native and Unity to work like Unreal, as you suggested.

[kring]

Ok that's done and this is ready.