Rethink propagation for elements with opt-in with requirement in signature

[TheMrMilchmann]

In the current implementation, there are some cases where it is possible to propagate requirements despite using OptIn. This occurs when the signature of an element annotated with @OptIn contains a type that has an opt-in requirement.

For example, look at the class below with a focus on the field. Here, myField is essentially propagating the requirement despite being annotated with @OptIn.

class MyClass {

  @OptIn(MyMarker.class)
  MyMarkedClass myField;

  void doSomething() {
    System.out.println(myField.toString()); // This will fail without opt-in
  }

}

This is consistent with how propagation works in Kotlin, but it might not be what we actually want here. Instead, we might want to change the definition of @OptIn to apply only to enclosed trees (e.g., method body, field initializer) and require explicit propagation otherwise. E.g.,

class MyClass {

  @MyMarker;
  MyMarkedClass myField;

  @OptIn(MyMarker.class);
  Object myOtherField = new MyMarker();

}