Resolve inconsistency between getPropertyIds and getPropertyNames

[sanjeetsuhag]

For 3DTILES_metadata, classes like TilesetMetadata, TileMetadata and GroupMetadata have a property called getPropertyIds(), whereas, ModelFeature and Cesium3DTileFeature have getPropertyNames. These should ideally all have the same signature.

We should go with getPropertyIds.

[lilleyse]

Since getPropertyNames is part of the public API lets deprecate it in the upcoming release (CesiumJS 1.95) and remove it three months from now (CesiumJS 1.98).

For the PR:

• Add getPropertyIds wherever getPropertyNames appears. Update any code and sandcastles to use getPropertyIds
• Mark getPropertyNames as deprecated. See Model.js#L708-L730 for an example.
• Note the deprecation in CHANGES.md under the CesiumJS 1.95 release.

After the PR is merged, open an issue to remove getPropertyNames and assign the label remove in 1.98 (you may have to create the label). See #10416 for an example.

[javagl]

I actually stumbled over this when creating the sample sandcastles (and the fact that // It's all just metadata, eventually wasn't resolved by the fact that I used an obscure approach to obtain what I then called "property keys", once being IDs and once being names). (I'll update thes latest versions of these sandcastles when this is merged).

The more technical question is whether this leads to the respective classes actually being what is referred to as an 'implementation of an interface' in the Java world, with the interface being MetadataEntity here. The name MetadataEntity does not appear publicly yet. I wondered whether the goal was to be able to say: "Whatever you have there, if it is 'metadata', then you can call these functions on it". But maybe that's beyond the scope of this issue and the PR.