OptIn: KT-48890 related changes

See details in https://youtrack.jetbrains.com/issue/KT-48890

proposals/opt-in.md

@@ -197,13 +197,8 @@ fun foo(s: String) {}
 ## OptIn markers and overridden declarations
 
 As a general rule, marker annotation should present either at base and overridden declarations together,
-or at none of them. 
+or at an overridden declaration only, or at none of them. 
 Using marker on base declaration only provokes error or warning on overridden declaration, depending on marker `RequiresOptIn.level`.
-Using marker on overridden declaration only is normally forbidden (see `bar` example below)
-because compiler usually cannot guarantee that exactly overridden function is called (see `base.bar` call).
-The exception to this rule is the situation when base class has the same marker, 
-in this case it's allowed to have the same marker on overridden declaration without marker on base declaration.
-The reason of this exception is marker contagiousness in lexical scopes (see chapter about it below). 
 
 ```kotlin
 open class Base {
@@ -213,8 +208,6 @@ open class Base {
  @ShinyNewAPI
  open fun foooo() {}
 
- open fun bar() {}
-
  @ShinyNewAPI
  open fun baz() {}
 }
@@ -226,30 +219,9 @@ class Derived {
  @OptIn(ShinyNewAPI::class)
  override fun foooo() {} // OK!
 
- @ShinyNewAPI
- override fun bar() {} // ERROR! Base declaration isn't annotated
-
  // Overriding experimental declaration
  override fun baz() {} // ERROR/WARNING (depending on ShinyNewAPI level)
 }
-
-fun use(base: Base) {
- base.bar() // Is it experimental or not?
-}
-```
-
-Exception example
-```kotlin
-@ShinyNewAPI
-open class Base {
- // No marker here
- open fun foo() {}
-}
-@OptIn(ShinyNewAPI::class)
-class Derived : Base() {
- @ShinyNewAPI // Ok
- override fun foo() {}
-}
 ```
 
 ## OptIn marker contagiousness (type usages)