Need a way in the Object Model to read enum values

[EricGriffith]

The Object Model provides access to some objects whose specific properties are determined by an enum value. KHR_lights_punctual light objects are a good example of this. The spot/innerConeAngle and spot/outerConeAngle properties are only available if the type is spot. For KHR_interactivity, we are missing a way to have logic that is conditional on these kinds of enum values because there are no rules in the object model for how to read the enum values.

I suggest one of two options:

1. Add the ability to read string data types to the object model and expose the enum values as read-only strings.
2. Expose the enums as integer values and provide a mapping from string to integer values in the object model.

[lexaknyazev]

The string type is not planned for the initial KHR_interactivity release and exposing string enums as integers would require extra maintenance in many places so that's not currently planned either.

The pointer/get operation is robust enough to not require any pre-existing conditions to read the pointer value. If spot/innerConeAngle does not exist, the value output value will be NaN and the isValid output value will be false.

That said, distinguishing between directional and point light types would be a better example because these two types don't have any unique properties. Nevertheless, a behavior graph is always bundled with the glTF asset it refers to and light types are immutable so reading them at runtime is not strictly required.

[EricGriffith]

A theoretical use case would be to have an interactivity graph that would iterate over all lights in an asset and adjust the spotlight params of the spotlights only. Of course, it's possible to do this by hard coding the list of spotlights, but seems like it adds needless complexity to do so.