When running JMX client on jigsaw build and JMX server on non-jigsaw build it becomes impossible to use 'ThreadMXBean.dumpAllThreads()'.

Any attempt ends with
```
Exception in thread "main" java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy0.dumpAllThreads(Unknown Source)
at threadinfotest.ThreadInfoTest.main(ThreadInfoTest.java:36)
Caused by: java.io.InvalidObjectException: Failed to invoke from(CompositeData)
at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory.invalidObjectException(java.management@9.0/DefaultMXBeanMappingFactory.java:1442)
at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeBuilderViaFrom.fromCompositeData(java.management@9.0/DefaultMXBeanMappingFactory.java:1029)
at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeMapping.fromNonNullOpenValue(java.management@9.0/DefaultMXBeanMappingFactory.java:927)
at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$NonNullMXBeanMapping.fromOpenValue(java.management@9.0/DefaultMXBeanMappingFactory.java:140)
at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$ArrayMapping.fromNonNullOpenValue(java.management@9.0/DefaultMXBeanMappingFactory.java:591)
at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$NonNullMXBeanMapping.fromOpenValue(java.management@9.0/DefaultMXBeanMappingFactory.java:140)
at com.sun.jmx.mbeanserver.ConvertingMethod.fromOpenReturnValue(java.management@9.0/ConvertingMethod.java:131)
at com.sun.jmx.mbeanserver.MXBeanProxy.invoke(java.management@9.0/MXBeanProxy.java:168)
at javax.management.MBeanServerInvocationHandler.invoke(java.management@9.0/MBeanServerInvocationHandler.java:258)
... 2 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9.0/Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9.0/NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9.0/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9.0/Method.java:530)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9.0/Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9.0/NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9.0/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9.0/Method.java:530)
at sun.reflect.misc.MethodUtil.invoke(java.base@9.0/MethodUtil.java:261)
at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeBuilderViaFrom.fromCompositeData(java.management@9.0/DefaultMXBeanMappingFactory.java:1026)
... 9 more
Caused by: java.lang.IllegalArgumentException: Unexpected composite type for ThreadInfo
at sun.management.ThreadInfoCompositeData.validateCompositeData(java.management@9.0/ThreadInfoCompositeData.java:449)
at sun.management.ThreadInfoCompositeData.getInstance(java.management@9.0/ThreadInfoCompositeData.java:75)
at java.lang.management.ThreadInfo.<init>(java.management@9.0/ThreadInfo.java:269)
at java.lang.management.ThreadInfo.from(java.management@9.0/ThreadInfo.java:845)
... 20 more
```

This has been caused by adding properties to StackTraceElement in JDK 9 Jigsaw (#61744adb0fa2, #a4f21cbdc2d4) without doing corresponding changes to ThreadInfoCompositeData and StackTraceElementCompositeData classes so they are able to consume CompositeData representation from older JVMs.