DateFormatter's in-memory date format cache is never invalidated when a date format changes

Problem/Motivation

Once a date format is used during a request, the entity object stays with the formatter till the end of the request. If the date format is changed afterwards, the formatter does not pick up the change and continues using the old pattern. This can affect processes which updates a date format and then formats a date in the same process. Eg. Config import, update hooks, batches, migrations, or Drush commands. I encountered it in workspace switching while working on the workspace_config issue.

Steps to reproduce

Run the following script

$f = \Drupal::service('date.formatter');
$c = \Drupal\Core\Datetime\Entity\DateFormat::load('new_format');
if (!$c) {
  $c = \Drupal\Core\Datetime\Entity\DateFormat::create([
    'id' => 'new_format', 'label' => 'Probe', 'locked' => FALSE, 'pattern' => 'j M Y',
  ]);
  $c->save();
}
print $f->format(0, 'new_format', '', 'UTC') . PHP_EOL;   // 1 Jan 1970
\Drupal\Core\Datetime\Entity\DateFormat::load('new_format')->setPattern('Y')->save();
print \Drupal\Core\Datetime\Entity\DateFormat::load('new_format')->getPattern() . PHP_EOL;  // Y
print $f->format(0, 'new_format', '', 'UTC'); // 1 Jan 1970 (expected - 1970)

I saved it in a php file and used drush scr to execute it.

Proposed resolution

Replace static cache with in memory cache

Remaining tasks

MR & Test

User interface changes

None

Introduced terminology

None

API changes

TBD

Data model changes

None

Release notes snippet

TBD