Refined isEffectivelyFinal logic for sealedness.

If the enclosing class of a method is sealed and has only final
subclasses, then the method is effectively final in the sealed class if
none of the subclasses overrides it. This makes it possible to inline
more methods without explicitly marking them final.

Note that the test doesn't fail before this patch due to SI-6142,
a bug in the optimizer, but here's a bytecode diff to prove it:

  @@ -16,8 +16,10 @@ public final class Test$ {
       Code:
   : getstatic                      // Field Foo$.MODULE$:LFoo$;
   : invokevirtual                  // Method Foo$.mkFoo:()LFoo;
  +: pop
   : bipush
  -: invokevirtual                  // Method Foo.bar:(I)I
  +: iconst_1
  +: iadd
   : ireturn

And the test in neg, which is manually made to fail due to the absence
of inline warnings, correctly refuses to inline the methods.

Review by @dragos.

1 files changed, 4 insertions, 0 deletions

diff --git a/test/files/neg/sealed-final-neg.check b/test/files/neg/sealed-final-neg.check
new file mode 100644
index 0000000000..500d23f49a
--- /dev/null
+++ b/test/files/neg/sealed-final-neg.check
@@ -0,0 +1,4 @@
+sealed-final-neg.scala:41: error: expected class or object definition
+"Due to SI-6142 this emits no warnings, so we'll just break it until that's fixed."
+^
+one error found