Static members in CLR types act like instance members when marshalled to JS

[TeamDoodz]

Version used

4.0.3

Describe the bug
When adding a CLR type reference to an engine via TypeReference.CreateTypeReference, static members in the type act the same way as instance members when used in JS.

To Reproduce

using Jint;
using Jint.Runtime.Interop;

internal class Program {
	static void Main(string[] args) {
		Engine engine = new Engine();
		engine.SetValue("ExampleType", TypeReference.CreateTypeReference<ExampleType>(engine));
		
		// Static members can be acessed as if they were instance members:
		Console.WriteLine(engine.Evaluate("JSON.stringify(new ExampleType())").ToString()); // Expected: {"Value": 0}, Actual: {"TestProperty": 5, "Value": 0, "Test": 5}
		Console.WriteLine(engine.Evaluate("new ExampleType().Test").ToString()); // Expected: undefined, Actual: 5
		Console.WriteLine(engine.Evaluate("new ExampleType().TestProperty").ToString()); // Expected: undefined, Actual: 5
		Console.WriteLine(engine.Evaluate("new ExampleType().TestMethod").ToString()); // Expected: undefined, Actual: function ExampleType.TestMethod() { [native code] }
		
		// Calling static/instance members using the type name works as expected, though:
		Console.WriteLine(engine.Evaluate("ExampleType.Test")); // Expected: 5, Actual: 5
		Console.WriteLine(engine.Evaluate("ExampleType.Value")); // Expected: undefined, Actual: undefined
	}
}

public struct ExampleType {
	public static readonly int Test = 5;
	public static int TestProperty => 5;

	public int Value;

	public static bool TestMethod() => true;
}

Expected behavior
Attempting to read static members on an object instance should return undefined, and stringifying an object instance should not include static fields/properties in the result.

Additional context

This is especially problematic for types that contain static members of themselves (such as Guid with Guid.Empty), as attempting to stringify instances of these types would result in a cyclic dependency.

[lahma]

This would probably be a breaking change. Would you like to propose a PR and check how existing tests behave?

[TeamDoodz]

OK, I'll do that.

[TeamDoodz]

I've made my changes and they do seem to break two existing tests: CanGiveCustomNameToInteropMembers and ShouldStringifyNetObjects; both of which rely on static members being accessible from object instances. Do you still want me to make the PR?

[lahma]

I think this just needs some think trough, generally exposing statics sounds wrong. Usually checking how JS treats such things with Object.getOwnPropertyNames() gives some guidance. For example, Math.E should show similar behavior like double.MaxValue when thinking about static properties.

[TeamDoodz]

Looking at JS's own static keyword, it behaves about the same as .NET statics do; they aren't accessible from object instances as demonstrated here (but do show up in Object.getOwnPropertyNames()). IMO, if this is how both JS statics and .NET statics function then I see no reason why .NET statics marshalled into JS shouldn't also act this way.

[lahma]

I've done a bit simpler approach with #1981 which also allows reverting back to old behavior if needed.