Resource initialization after a `super()` call should be permitted.

Consider the following code, which is checked in as InitializationAfterSuperTest.java:

import java.io.IOException;
import java.net.Socket;
import org.checkerframework.checker.calledmethods.qual.EnsuresCalledMethods;
import org.checkerframework.checker.mustcall.qual.InheritableMustCall;
import org.checkerframework.checker.mustcall.qual.Owning;

@InheritableMustCall("close")
public class InitializationAfterSuperTest implements AutoCloseable {

  @Owning Socket mySocket;

  public InitializationAfterSuperTest(@Owning Socket mySocket) {
    super();
    this.mySocket = mySocket;
  }

  @EnsuresCalledMethods(value = "mySocket", methods = "close")
  @Override
  public void close() throws IOException {
    mySocket.close();
  }
}

The Resource Leak Checker issues this error:

InitializationAfterSuperTest.java:14: error: [required.method.not.called] @MustCall method close may not have been invoked on field mySocket or any of its aliases.
    this.mySocket = mySocket;
                  ^
  The type of object is: java.net.Socket.
  Reason for going out of scope:  Non-final owning field might be overwritten

Initialization after a super() call is a common pattern and the checker should permit it, at least by default. (There could be a flag to make the checker issue a warning, on the off chance that super() made a call that assigned mySocket.)

Start with the checked-in InitializationAfterSuperTest.java example and reproduce the Resource Leak Checker diagnostic for the assignment after super(). Trace the checker’s handling of owning fields during constructor initialization; done means this initialization pattern is accepted by default without the reported required.method.not.called error.