Add CacheableDependencyInterface and related cache metadata to TranslatedImmutableConfig object

Hi @bvoynick

Thank you very much for your inputs and efforts for the merge request! :-)

I very much like the idea of handling cache properly. However I don't quite understand the use case in this particular example.

Could you provide an example where this comes into play? At the moment, the config is read directly on call, and then held in local memory. How does cache metadata affect this process?

The use case is downstream rendering or other things that may need cache metadata.

For example, let's say I render something using text from a config. Using core's ImmutableConfig object I could write code like this:

$config = \Drupal::config('my_config');
$render_array = [
  '#plain_text' => $config->get('text_property'),
];
CacheableMetadata::createFromObject($config)
  ->applyTo($render_array);

But what if I want to use translated_config? Since TranslatedImmutableConfig doesn't implement the CacheableDependencyInterface, currently my code would have to look something like this:

$translated_config = \Drupal::service('translated_config.helper')->getTranslatedConfig('my_config');
$render_array = [
  '#plain_text' => $translated_config->get('text_property'),
  '#cache' => [
    'tags' => [
      'config:my_config',
    ],
    'contexts' => [
      'languages:language_interface',
    ],
  ],
];

Which requires me to know the right metadata to hardcode.

Or alternately, I could make my own separate call to \Drupal::config('my_config') as in the first example, using the TranslatedImmutableConfig object for values only and not metadata.

But anyhow, that's the purpose of this feature request. To have the same cache-related "developer experience," when it comes to handling cache metadata, as with the core ImmutableConfig object, where one can simply send it to the right addCacheableDependency() or similar method.