`Map.replace(K, V, V)`: Make `oldValue` `@Nullable`

We have it as parametric nullness in Map itself and in ConcurrentMap and presumably other subtypes:

• https://github.com/jspecify/jdk/blob/39339b00f9fcf290db3d40537717c0bfe42e0884/src/java.base/share/classes/java/util/Map.java#L955
• https://github.com/jspecify/jdk/blob/39339b00f9fcf290db3d40537717c0bfe42e0884/src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java#L226

Android has it as @Nullable: https://cs.android.com/android/platform/superproject/main/+/main:libcore/ojluni/annotations/sdk/nullability/java/util/Map.annotated.java;l=72;drc=31fc4306a5baa196245ae16f79009b632ccbe667

As a result of that difference, an Android nullness check in Google's depot gets upset.

It seems like @Nullable would make sense, given the concept of the method and the default implementation: You can't hurt anything by passing null.

But that might be trouble for Kotlin? https://github.com/JetBrains/kotlin/blob/e32761ba660d67e60ddcd3cd1e798331b9f6d9d3/core/compiler.common.jvm/src/org/jetbrains/kotlin/load/java/typeEnhancement/predefinedEnhancementInfo.kt#L169-L174

And we'd want to see if at least some implementations would reject null, similar to contains. (That likely wouldn't change our direction for the interface, but we'd want to keep the type with parametric nullness (or make it non-null) for any such implementations.)

Start with the referenced Map.java and ConcurrentMap.java declarations, then compare Android's annotated Map.annotated.java and Kotlin's predefinedEnhancementInfo.kt. Check relevant implementations for null rejection and determine whether the interface annotation is compatible with Kotlin. Done means the interface and affected implementations have consistent nullness annotations without breaking the compatibility concerns described.