Callout bindings should be more flexible wrt visibility

[stephan]

OTJLD §3.1(i) states that shorthand callout bindings define role methods with default visibility. Now that we enforce that default visible role methods cannot be accessed from outside the role (cf. #194), such shorthand bindings are much less useful.

First, if the corresponding base feature is already public or protected, the callout should inherit this visibility (should generally inherit this visibility by default).

Second, a shorthand callout binding should be allowed to optionally specify a visibility modifier.

Need to check some consistency constraints, like not reducing the visibility of something inherited.

[stephan]

r19519/r19520 provide the general specification and implementation. See also OTJLD §B.1.2 for an overview (2 new entries regarding callout bindings).

[stephan]

Many tests successfully apply this feature, e.g.:
positive:

• 3.1.9-otjld-nonexisting-base-method-3 -- public callout
• 3.1.14-otjld-callout-without-role-method-1 -- inherit protected visibility

negative:

• 3.1.10-otjld-binding-states-modifier-1 -- modifier in callout short
• 3.1.10-otjld-binding-states-modifier-2 -- modifier on RHS
• 3.1.10-otjld-binding-states-modifier-3 -- non-visibility modifier
• 3.1.3-otjld-concrete-callout-binding-1f -- reducing visibility

And many more throughout all of jacks.

[stephan]

BTW: see also #196 for supporting this new feature by a quickfix.

[stephan]

Additional improvements while adjusting the jacks suite for strict adherence ot OTJLD §1.2.1(e):

• r19521: don't inherit other bits than visibility
• r19523: fix detection whether modifier is legal or not
• r19525: include callout modifier in flattening (needed for quickfix etc.)
• r19534: treat static role methods in the same way as non-static

[stephan]

r19552 relaxed the rule for one specific case:

A callout to a public base feature has a non-public role type in its signature. Now the callout inherits publicness from its base, causing the compiler to complain that the roles in the signature cannot be externalized. This is relaxed by reporting this as a warning only, if the enclosing role itself is non-public.

Rationale: the public method cannot be invoked from outside the team anyway. We keep the diagnostic, however, because a subclass of this role might be public and then it's difficult to tell, what's wrong: a previously legal callout/method becomes illegal because it is now visible to a greater audience..

For consistency, this relaxation applies to callouts and methods alike.