Collection.removeAll and retainAll can throw NullPointerException even if annotated conservatively

From their docs (emphasis mine):

Throws:
...
NullPointerException - if this collection contains one or more null elements and the specified collection does not support null elements (optional), or if the specified collection is null

That means that it's often safe to call removeAll and retainAll only if:

• the receiver collection has a non-null element type (currently not expressible; see #3203 ), or
• if the argument collection supports calls to contains(null) (which seems harder to express, short of permitting calls to removeAll and retainAll only if the argument itself has a null element type)

Putting those together, maybe what we actually want is something like the following...?

<E extends @PolyNull Object> boolean removeAll(Collection<@PolyNull ? extends Object> c);

If I'm understanding right, that may still be more conservative than we'd like (since it ought to be safe to pass, e.g., an ArrayList<@NonNull String>, which supports null queries even though it doesn't contain nulls), but it may be an improvement.

Here's a way to get NPE with the current signatures:

import java.util.ArrayList;
import java.util.List;
import java.util.Set;
import java.util.TreeSet;
import org.checkerframework.checker.nullness.qual.Nullable;

public class QueryNull {
  public static void main(String[] args) {
    List<@Nullable String> c = new ArrayList<@Nullable String>();
    c.add(null);
    Set<String> toRemove = new TreeSet<String>();
    c.removeAll(toRemove);
  }
}

Start by reproducing the QueryNull example and reading the Java Collection.removeAll and retainAll contracts, then inspect the current signatures in relation to issue #3203. Done means the annotations model the documented null behavior without permitting the shown unsafe call, with tests covering the revised signatures.