review1: refactor(role): add CtRole.TYPE_MEMBER

[pvojtechovsky]

Adds CtRole.TYPE_MEMBER, which will be needed by #1614 and which makes sense for CtPath clients too.

@tdurieux does the sniper mode need to distinguish between CONSTRUCTOR, FIELD, ... Would not it be simpler to fire change listener even using CtRole.TYPE_MEMBER ???

If it would be simpler, then implementation of CtTypeImpl should fire CtRole.TYPE_MEMBER instead of CONSTRUCTOR, FIELD, METHOD, ... roles.

[monperrus]

OK to add the role now, the intercession event can be modified later on. One solution is to attach more than one role to an intercession event.

[pvojtechovsky]

Another solution would be to express inheritance between roles.

assertSame(CtRole.TYPE_MEMBER, CtRole.FIELD.getSuperRole())
assertNull(CtRole.TYPE_MEMBER.getSuperRole())

Then we would fire event with CtRole.FIELD - as now, and client might use getSuperRole() to access more generic role if needed.

May be the opposite would be interesting too CtRole CtRole.getSubRole(Class)
CtField field = ...
assertSame(CtRole.FIELD, CtRole.TYPE_MEMBER.getSubRole(field.getClass())

WDYT?

[monperrus]

That's also an interesting solution, yes. The one with multiple roles by event seems slightly easier (no need to commit to a predefined hierarchy).