Rename function parameters using a reserved keyword

[HGuillemet]

Appends a _ to the name of function parameters when they clash with a Java reserved keyword.

[saudet]

Please add those in here:
https://github.com/bytedeco/javacpp/blob/master/src/main/java/org/bytedeco/javacpp/tools/InfoMap.java#L171

[HGuillemet]

Ok, I hadn't realized that the infoMap was queried for function parameter names.

[saudet]

It should, for that particular case, it's not?

[HGuillemet]

Yes it is. New commit adds _ to parameter names like interface.

[HGuillemet]

Added another small fix to prevent generation of successive ... in containers

[HGuillemet]

Since this PR is still opened, adding another small fix:
When annotations are defined in info on constructors, they are set on allocate.
However, there is at least one annotation we want on the Java constructor: @Deprecated. This commits fixes that. Not in a very nice way. If you have an idea about how to do it better...

[saudet]

What happens if we don't use filterJavaAnnotations()? Let's name it maybe constructorAnnotations()?

[HGuillemet]

Without the commit, if we have an info like new Info("deprecated").annotations("@Deprecated")) and a C++ constructor is deprecated, the @Deprecated annotation goes on allocate and not on the public Java constructor.
The idea of filterJavaAnnotations is to retain from a string of annotations only those that are meaningful for non-native Java methods, thus the name.
I only though of @Deprecated but there may be others. Ideally this would be all non-JavaCPP annotations.

`

[saudet]

Right, but can we just leave all annotations without any issues? Does it break something?

[HGuillemet]

Ah. You mean place all annotations on both allocate and the constructor ?
There are already the JavaCPP parameter annotations that are placed uselessly on constructor parameters, so why not also place the method annotations, if you prefer...

[saudet]

Right, it's not exactly useless, so let's so that for the method annotations too if it works

[HGuillemet]

Does it break something?

In fact it does, because some annotations that are valid on allocate (an ElementType.METHOD) are not on constructors (an ElementType.CONSTRUCTOR), like @Adapter.
So I guess we must filter the annotations to place on constructor according to some white list (I suggested: @Deprecated only).

[saudet]

Sounds good

[HGuillemet]

Ok, Can you merge if you agree with these changes ? I'd like to push an update or Pytorch presets that uses them.