NullableResponse<T> should implement IDisposable

[heaths]

Because ValueResponse<T> takes a Response as a parameter and holds onto it, and because Response implements IDisposable, ValueResponse<T> should dispose the Response because it's effectively taking ownership of it. However, because ValueResponse<T> is internal and we could possibly expose a NullableResponse<T> in a public API (see #33767 for context), we should implement IDisposable on NullableResponse<T>. It'd be a virtual no-op but overridden in ValueResponse<T>.

[annelo-msft]

Making NullableResponse<T> IDisposable would make Response<T> IDisposable and require usage patterns for all clients to change to dispose the return values of all service method calls. Given how broadly this would impact users, I don't think we would want to implement this in Azure.Core. Service methods are responsible for disposing the response (HttpMessage should be in a using block in service method implementations), so Response is disposed when the service method returns, while remaining usable for end-user purposes. In cases where resources that need to be disposed (such as network streams) are returned to the end user, convenience methods should be extracting those values from the message and response and returning types like Response<Stream> while making it clear in the refdocs that the end-user needs to dispose these values.

@heaths, if there's a specific case you're concerned about in a specific client, I'm happy to reopen and find the right solution for that case.