Add Info.beanify() to add JavaBeans-style prefixes for getter and setters of member variables generated by Parser

[equeim]

Kotlin's feature of automatic conversion of Java getters/setters to properties requires them to have JavaBeans-style prefixes (unless class is a record). Parser doesn't add them which makes classes generated by it to be awkward to use in Kotlin.

[saudet]

Let's name that Info.beanify? And instead of annotating with @Name, let's add the logic for that in Generator instead.

[equeim]

And instead of annotating with @name, let's add the logic for that in Generator instead.

How will Generator distinguish between member that was beanified and member which C++ name actually starts wit "get"? If we have both getter and setter, then we can make a guess because parts of method names after get/set prefixes are the same and therefore they are getter and setter and extract actual member name by stripping prefix and lowercasing first character. However, we can't do that if we have only getter.

Also, if C++ member name is capitalized, then its getter/setter method name will be the same as for member that start with lowercase character.

[saudet]

And instead of annotating with @name, let's add the logic for that in Generator instead.

How will Generator distinguish between member that was beanified and member which C++ name actually starts wit "get"? If we have both getter and setter, then we can make a guess because parts of method names after get/set prefixes are the same and therefore they are getter and setter and extract actual member name by stripping prefix and lowercasing first character. However, we can't do that if we have only getter.

Also, if C++ member name is capitalized, then its getter/setter method name will be the same as for member that start with lowercase character.

Conflicts can occur, yes, it happens with the current scheme as well, that's not a problem. That's what the @Function, @MemberGetter, @Name, etc annotations are for. We can use them when needed, but it's nice to support common cases without tons of annotations everywhere. I haven't seen a lot of C++ APIs that use JavaBean-like namings, so I don't foresee any problems.

[saudet]

Hum, I've been testing this against the presets, and the get/set pattern is used in C++ APIs more frequently than I thought.
Let's revert that to the Generator-less solution, unless you have a better idea?

/cc @HGuillemet

[equeim]

Not really. I realize that Parser-only solution is not very convenient when writing Java classes by hand instead of using Parser, but it still the most reliable one and (IMO) least confusing. I suspect that it is possible to make Generator detection work better, but it will add event more complexity to it. So I reverted back to previous solution (renaming to beanify).
BTW, one of CI jobs seems to be stuck.