Swap using the low-level FileSystem in favor of more advanced FileRepository

Problem/Motivation

This is a follow-up of ACMS-4080 MR!71, in which Asset::getLocalThumbnailUri() (source) has introduced an implementation flaw: currently it uses two different utilities (\Drupal\Core\File\FileSystem and \Drupal\file\FileRepository) for the same purpose of handling locally stored images. Apparently, in most cases, it works, but at least one situation has already been found when do not.

After the reinstallation of the module, during the creation of a new media item (usually by inserting via the Media Library modal window), if the {webroot}/sites/default/files/acquia_dam_thumbnails directory already contains a thumbnail image in its {asset_id}/ subfolder with the {version_id}.png filename (for example, as a residue of an earlier installation), then the getLocalThumbnailUri() fails when trying to clear up the space before creation (around lines 555-560):

1. First, the scanDirectory() of FileSystem reports that there are files, which is true.
2. Then, in response, the FileRepository is ordered to delete those files.
3. However, this is impossible: there are no managed file entities that exist in the DB anymore (as we're after a reinstallation).

Steps to reproduce

1. Install and configure the module as usual
2. Manually create a {webroot}/sites/default/files/acquia_dam_thumbnails/{asset_id}/{version_id}.png file with a given DAM asset existing in Widen.
3. Browse that DAM asset and try to insert into either a reference field or a WYSIWYG editor.
   • Actual: nothing happens on the GUI, error appears in the console
   • Expected: media item should be created properly.

Proposed resolution

Rework the file-handling logic to rely entirely on the FileRepository utility, which represents a higher abstraction layer rather than directly instructing disk operations with FileSystem.

Remaining tasks

More feedback would be appreciated before hitting the lines of code to change anything.