Infer null-safety from type variables in Kotlin extensions when possible

[sdeleuze]

As discussed in #22682 for specific JdbcOperations Kotlin extensions case, we could make null-safety more accurate by inferring null-safety from type variable in order to leverage the null-safety declared by the user instead of hardcoding the nullable nature of the return value, which forces for example Kotlin developers to use !! systematically and is not consistent with Java original signature.

PropertyResolver, JdbcOperations and RestOperations Kotlin extensions should be modified accordingly.

Based on my tests, it seems Java type inference is not clever enough to infer null-safety from type variable level @Nullable annotation so we will have to wait #20496 to apply that as well to Java methods.

[mplain]

@sdeleuze hello!
In this commit you changed this:

inline fun <reified T: Any> RestOperations.getForObject(url: String, vararg uriVariables: Any): T? = 
   getForObject(url, T::class.java, *uriVariables)

to this:

inline fun <reified T> RestOperations.getForObject(url: String, vararg uriVariables: Any): T = 
   getForObject(url, T::class.java, *uriVariables) as T

As a result, when I use it like getForObject<String>(), if the response body is null, I get a ClassCastException (null cannot be cast to non-null type). Not even a NullPointerException, but a ClassCastException. Is this intended?
In http communication there's always a risk of getting a 200 response without a body. I'd rather check for nullability myself.
If I want to get a nullable result, I could write getForObject<String?>(), or call the java function directly (which is @nullable)
I'm just trying to understand what happened here, was it intended or not...