Detangle some material generation logic from CesiumFeaturesMetadataComponent

[j9liu]

A lot of the boilerplate in CesiumFeaturesMetadataComponent is necessarily entangled, but there are some parts that can be moved out and made reusable. I also made some changes to file names in accordance with our style guide.

This PR does the following:

• Create GeneratedMaterialUtility namespace
• Move some common functions, constants, etc. into the new namespace
• Update CesiumFeaturesMetadataComponent.cpp for the changes
• Drops the Cesium from EncodedFeaturesMetadata, since it isn't public API
• Drops the Cesium from EncodedMetadataConversions, since it isn't public API

[j9liu]

This should be ready for a review, provided CI passes this time ^_^

[j9liu]

CI is now passing thanks to #1649 🙌

[kring]

I noticed a strange problem. I'm not sure if it's new in this branch or not. This happens in main, too.

1. Create a new empty level in the Samples project.
2. And Cesium SunSky, Cesium World Terrain + Bing Maps Aerial, and Cesium OSM Buildings using the Cesium panel.
3. Click the Cesium OSM Buildings Actor in the Outliner and add a CesiumFeaturesMetadata component. It will be selected automatically.
4. Click the Auto Fill button.
5. Open Model Metadata -> Property Tables -> Index [ 0 ] -> Properties and scroll down until you find cesium#longitude. Expand it and then expand Property Details inside it. Notice that the "Component Type" is Int 8. It should be Float64.
   
6. Delete all of the properties by clicking the trash can icon near Model Metadata -> Property Tables -> Index [ 0 ] -> Properties.
7. Press Auto Fill again. The property type of cesium#longitude will still be Int 8. 🐛
8. Delete the properties again, as in step (6).
9. Click the main Cesium OSM Buildings Actor at the top of the Details panel.
10. Click Refresh Tileset
11. Click the CesiumFeaturesMetadata component again.
12. Click Auto Fill
13. Expand cesium#longitude and notice that the property type is now correctly Float 64. It seems that refreshing the tileset after the metadata component is added fixes something.
    

[kring]

Looks good to me! Just minor comments that might not even require any action.

[kring]

This is probably fine, but we do need to keep sight of the fact that even private types pollute a global namespace in Unreal builds. In shipping builds, every symbol - public or private, across all plugins/modules - get dumped into one executable. So if we have a class name that conflicts with one in some other plugin, users may get linker errors when they combine the two plugins.

I'm remembering now that there's a line in our style guide saying private types shouldn't be prefixed with Cesium. That reflects our common practice, but I think it may not have been a well-considered choice. It's fine as long as conflicts are unlikely.

I think if I were starting over with Cesium for Unreal today, I'd probably put everything in a CesiumForUnreal namespace (except maybe UObjects? I'm not sure) in order to avoid the issue entirely.

But anyway, the chance of conflict in this particular case is really low, so I'm fine with the rename. I just wanted to mention it so we don't go renaming all the private types.

[j9liu]

Thanks @kring for the review! I was able to reproduce the bug you found.

Stepping through the debugger -- it looks like some tiles actually have a "valid" cesium#longitude property that is an Int8 scalar. But then other tiles have the property as a Float64. The "Auto Fill" system makes a blanket assumption that metadata properties are uniformly defined across the tileset, and that assumption falls apart for something like OSM Buildings.

I'd still like to step through and see how those Int8 properties are being initialized -- it might be a bug in cesium-native, for instance -- but I think this is just demonstrating the fundamental flaw in the "Auto Fill" system, because it simply picks up the first type definition it finds.

[kring]

Thanks @j9liu!