add TypeInfo to preserve more type information

[ZZZank]

This PR added "TypeInfo" as another representation of Java type, in an effort to preserve more type information than what a Class<?> can provide, especially information on type variable and parameterized type

• TypeInfo can be converted back to the exact class using TypeInfo#asClass(), in other words, this method should and will return the class represented by this type after Java erased its generic type info.
  • for type variable, it will return the first declared bound, or Object.class if not explecitly declared bound
  • for parameterized type, it will return what its raw type will return
  • for wildcard type, it will return the first declared bound
• another benifit of using TypeInfo is that we can pre-compute results of some commonly used data, for example TypeInfo#getTypeTag() and TypeInfo#isObject()
• There's also a method TypeInfo#consolidate(...), which is reserved for implementing Java Generics support, you can find an example implementation at Java Generics support KubeJS-Mods/Rhino#55

[rPraml]

Nice to see progress in this area.

BTW: There is still an old PR from me #827 which might do the same. I only took a short look at your PR (and noticed, there are no tests, yet), so I cannot say, how similar they are.

[ZZZank]

Yes, the final purpose of this PR and #827 are the same: introduce Java Generic support. But I decided to use TypeInfo instead of java.lang.reflect.Type, for flexibility and potentially better performance:

• creating a new TypeInfo allows us to add APIs for different types without having to use many, many instanceof, for example TypeInfo#asClass(), which provides the same feature as JavaTypeInfo#getRawType in RFC: Add generic type support and improve java.util.{List,Map} handling #827, but in another way
• another benefit is that we can skip computation early if the result is determined for a certain type, for example TypeInfo#isFloat(), we can make an ArrayTypeInfo always return false since an array is impossible to be float or Float

And about tests, I'm working on a test for TypeInfo itself, and since this PR didn't actually introduce Generic support, I think tests for generic accessing can be skipped for now?

---

And a question, my expectation is that there will be 3 parts (so 3 PRs) for Java Generic support:

• TypeInfo
• Generic support for method/constructor
• rewrite field handling to introduce Generic support for it

Should I combine them into one large PR or split into 3?