KAFKA-19028: Expose deleted configs to AlterConfigPolicy without changing configs()

[arnabnandy7]

Summary

An incremental DELETE of an unset topic configuration generates no ConfigRecord, so AlterConfigPolicy.RequestMetadata.configs() omits the key. A broker DELETE generates a record and appears in that map with a null value. This makes an explicit DELETE difficult for a policy to identify consistently across resource types.

This change preserves the existing configs() behavior and adds RequestMetadata.deletedConfigs(), which contains the names of all explicitly requested incremental DELETEs, including no-op topic deletions. It also adds configsWithoutNullValues() for policies that need the non-null entries from configs().

The existing public RequestMetadata constructor remains available. Legacy AlterConfigs requests report an empty deletedConfigs() set.

Compatibility

The map returned by configs() is unchanged, preserving the KRaft behavior that the ZooKeeper compatibility flag from KIP-1252 was designed to match. Policies can opt into the new deletion information without changing existing validation logic.

This adds methods to a public policy API; maintainer guidance on whether a KIP is required is welcome.

Testing

Updated controller unit coverage to assert the policy arguments for an unset topic DELETE, a stored topic DELETE, and an unset broker DELETE. Added API unit coverage for the new accessors and constructor, and verified that the legacy path reports no explicit deletions.

[arnabnandy7]

@chia7712 please review

cc @edoardocomar