Adds file upload deletion logging

[Godmartinz]

This adds logging for deletion of uploads across assets, accessories, licenses, consumables and components.
While components history is not currently surfaced, changes are reflected in the action_logs table.
[sc-28213]
Deletions have a trash icon:

This updates the uploads() relationships on all models mentioned above to exclude all filenames that have been deleted so the File Uploads tabs correctly reflect what is actually still being stored.

[what-the-diff]

PR Summary

• Improved File Deletion Handling: The system for deleting files has been upgraded across various controllers. Instead of directly removing files, the application now goes through an extra process called logUploadDelete($log->filename). This change ensures that we keep a record of the files that we delete, adding more transparency and potentially making it easier to recover any mistakenly deleted files.

• Established logUploadDelete Method: A fresh functionality called logUploadDelete($filename) has been put in place. Whenever a file is removed, this new method creates a record to document the action. This feature introduces a way for us to track and validate which files have been removed and when.

• Refined Query Logic for File Uploads: The way the system retrieves the list of uploaded files has been enhanced across multiple assets. In its latest form, the query process filters out any files marked as deleted and refrains from showing them in the uploads list. This ensures we maintain an accurate list of currently available files.

• Visual Cue for Deleted Files: The upload history now displays a trash icon next to the files that have been deleted. This serves as additional evidence of these deletions and makes it easier to identify them at a glance.

• Language Consistency for Deleted File Actions: To ensure our messaging about file deletions is consistent, a new translation string for 'upload deleted' has been added. This ensures that all related actions will be uniformly labelled, no matter their location or context, providing a coherent user experience.

[marcusmoore]

This is mostly solid but there are a couple inconsistencies we should fix up before merging.

1. Consumables don't show the filename like other histories do
2. Deleting a file update for a component hides uploaded action from the history view

3. you can still download a "deleted" file from a license history. It's not actually being removed.

This doesn't occur for the other first class items

Some of this might not be caused by this PR but we should probably make them uniform.

---

Also, should we include users in this? I think it's in the same boat as components where the file history isn't surfaced but can be.