Added generics generation in JNetReflector

[masesdevelopers]

Description

This PR contains:

• improvements in JNetReflector to create generics, meanwhile there are some fixes from previous version
  • most methods becomes properties: this can introduce a breaking change from previous version
• JNet introduces all classes, with generics too, generated using JNeReflector: still missing Listener and callbacks

Related Issue

Closed #142
Closed #143 with #38
Fix #130
Fix #132

Motivation and Context

How Has This Been Tested?

Tested locally

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[mariomastrodicasa]

Too big to be managed: the limit is 3000 files

[mariomastrodicasa]

Looking into the code generated it is possible to highlight this:

JNet/src/net/JNet/Generated/Java/Util/Collection.cs

Line 332 in 000f825

public bool RemoveAll<Arg0Extendsobject>(Java.Util.Collection<Arg0Extendsobject> arg0)

the corresponding Java code is:

boolean removeAll​(Collection<?> c)

I pretty sure the above C# code works, anyway for native types like long there is something like this:

JNet/src/net/JNet/Generated/Java/Util/PrimitiveIterator.cs

Line 236 in 000f825

public void ForEachRemaining<Arg0objectSuperlong>(Java.Util.Function.Consumer<Arg0objectSuperlong> arg0)

the Java code is:

void forEachRemaining​(Consumer<? super Long> action)

but in C# a long is sealed so we can remove the generic otherwise there isn't a right constraint in the code.

I will open an issue to write better this kind of code.