Revisit nullness of Collectors.toMap

It looks like we have the key types as nullable but the value type not? I would have guessed that they'd both be nullable.

• https://github.com/jspecify/jdk/blob/cba7f90d93c484f2930515aad2b7a7170b8799d6/src/java.base/share/classes/java/util/stream/Collectors.java#L1446
• https://github.com/jspecify/jdk/blob/cba7f90d93c484f2930515aad2b7a7170b8799d6/src/java.base/share/classes/java/util/stream/Collectors.java#L1550
• https://github.com/jspecify/jdk/blob/cba7f90d93c484f2930515aad2b7a7170b8799d6/src/java.base/share/classes/java/util/stream/Collectors.java#L1642

I wonder if part of the story here is that the ones that declare a mergeFunction would want a non-null type argument there? But, if so:

• We could accomplish that with @NonNull.
• It's not clear to me that a nullable type argument there would be wrong, just potentially inconvenient in some cases (and convenient in others).

I'm belatedly realizing that a Guava user had raised a related question before in https://github.com/google/guava/issues/6824. So part of the story might be that a more flexible signature has been difficult for some tools in the past. But I know that the Checker Framework improved its type inference a while back, so we should get some real-world data on this once we're able to import those changes to Google's monorepo.

(I noticed this as I was putting together https://github.com/jspecify/jdk/pull/146.)

Start by comparing the three Collectors.toMap declarations in src/java.base/share/classes/java/util/stream/Collectors.java at the referenced lines. Review the related Guava issue and consider the Checker Framework inference context; done means reaching a justified decision on nullness for keys, values, and mergeFunction, supported by real-world tooling data.