This PR fixes a bug that prevented a previously set deprecation from being cancelled. IfsetDeprecated() was called with an empty string, it would returnvoid without removing the existing deprecation entry.

This made it impossible for child classes or subsequent configurations to override and disable a deprecation set by a parent configuration.

The fix ensures that callingsetDeprecated('...', '') activelyunset()s the deprecation from the internal array, restoring the expected override behavior.

Example:

Given a base configuration (e.g., a parent class) that deprecates thehostname option, based on the documentation's example:

// In parent class:$resolver    ->setDefined(['hostname','host'])    ->setDeprecated('hostname','acme/package','1.2','The option "%name%" is deprecated, use "host" instead.'    );

A child configuration attempts toannul this deprecation:

// In child class:$resolver    ->setDeprecated('hostname','acme/package','1.3','');

Before (The Bug):
TheisDeprecated('hostname') method still returnedtrue, and resolving['hostname' => '...'] would incorrectly trigger anE_USER_DEPRECATED error.

After (The Fix):
The deprecation is correctly removed.isDeprecated('hostname') now returnsfalse, and no deprecation error is triggered when resolving the option.