Idea: Experimental feature flags for CesiumJS

Thinking about the future of the Model.js refactor (a large part of #9520), one concern is migration will prove difficult, as there are many, many intertwined features there.

To help avoid creating staging branches for many months on end, it would be nice if we had some standard mechanism for enabling/disabling experimental features. This way, users can try out new features before they are fully finished.

For example, for 3D Tiles it would be very helpful if the contents could do something along the lines of:

var model;
if (ExperimentalFeatures.enable3DTilesNextModel) {
    // Experimental version of Model. Basic rendering may work, 
    // but other features like animations and glTF 1.0 support are not yet implemented 
    // and may break.
    model = new Model2(...); 
} else {
    // Original Model.js implementation
    model = new Model(...);
}

Then applications only have to specify Cesium.ExperimentalFeatures.enable3DTilesNextModel = true to try the new version of Model.

This could be used for other large features in the future as well. The important thing would be to clearly mention that experimental features are subject to change from release to release, use at your own risk.

What are your thoughts, @sanjeetsuhag, @lilleyse, @ebogo1? Is ExperimentalFeatures something that would benefit CesiumJS in the long run? Are there any potential pitfalls to doing this?

[ptrgags]

@ebogo1 That’s a good point, though I think we should keep this simple, just a flat list of flags for now.

ExperimentalFeatures.enable3DTilesNextModel;
ExperimentalFeatures.enableMeshopt;

I plan to make a PR for this early next week. In the code I’ll include a block comment so we can describe best practices for this from the start. Some ideas:

• experimental features must have solid unit test coverage. This is not a replacement for a thorough PR review!
• experimental features are intended for large work-in-progress features when there’s a benefit to merging the code sooner (e.g. to avoid keeping staging branches around).
• experimental feature flags should ideally be short-lived - make it clear in the PR what needs to happen for the experimental feature to be promoted to a regular feature.

[ptrgags]

Closing this as ExperimentalFeatures is now available in the latest release.