[PP-1] Follow-up for #3364506: add deprecation once all simple config forms in core implement

Repurposing per #3364506-103: Add optional validation constraint support to ConfigFormBase and [-105].

#3364506: Add optional validation constraint support to ConfigFormBase landed!

#3382510: Introduce a new #config_target Form API property to make it super simple to use validation constraints on simple config forms, and adopt it in several core config forms is in review.

#3382510: Introduce a new #config_target Form API property to make it super simple to use validation constraints on simple config forms, and adopt it in several core config forms landed. That means this is now only blocked on #3384790: Update all remaining ConfigFormBase subclasses in Drupal core to use #config_target 🚀

#5 didn't explain how we could implement this deprecation in the >=10.2.x world.

Thanks to #3398891: Do not require the config in #config_target to be listed in getEditableConfigNames(), I see how we can now do that:

I propose that we make ConfigFormBase detect:

1. when getEditableConfigNames() returns anything other than the empty array
2. a deprecation is triggered in Drupal 11

Tricky thing here: for example \Drupal\search\SearchPageListBuilder uses not the base class, but the trait … and the trait does NOT have the #config_target functionality 🤔

AFAICT we'll need to deprecate in Drupal 11 only \Drupal\Core\Form\ConfigFormBase::getEditableConfigNames, not \Drupal\Core\Form\ConfigFormBaseTrait::getEditableConfigNames?

Tricky edge case: already (thanks to #3398891), a number of subclasses do not implement that method at all, and instead use RedundantEditableConfigNamesTrait;. That trait will become obsolete too!

Finally: is this issue now effectively a duplicate of #3400033: Deprecate \Drupal\Core\Form\ConfigFormBase::getEditableConfigNames() - use #config_target instead? Or vice versa?