Better handle inline files in file listing

[snipe]

This is a refactor to use a blade component for the file listing table tabs, and also changes the StorageHelper do a better job of what should be able to be displayed inline and what shouldn't. (Things that are not images or PDFs can still be inlined, but only if they are allow-listed, otherwise we will force a content-type: text/plain to prevent rendering within the browser.)

Still needs a little more refactoring, as previews for images are not showing up on objects other than hardware and users, and I'd like to shift more of that logic that's in the general helper into the StorageHelper where it makes sense, but I think this is a good start.

This solves a few issues:

• Prevents the execution of inline files unless their mimetype is allowed via the allow list (I see you, XML) and will force the browser to render as text if it's not in one of the allowed file types, preventing XXE attacks
• Abstracts the uploaded files table into an anonymous blade component, which solves many small inconsistencies in the views (table td wrapping where we have multiple buttons, etc)
• Does a more "pure" version of checking filetypes via php-fileinfo
• Better exception handling when a file doesn't exist, pulling this file check out of the controller and moving it into the StorageHelper where it seems better suited
• General code cleanup, moving and simplifying methods and removing ones that we don't use anymore
• Adds App/Helpers/StorageHelper to the app config

Testing

• Test uploading regular images, other accepted files (docx, pdf, etc) - make sure that ones that should not be allowed to be inlined:
  • do not have an active inline button
  • If you forge the URL (copy the download link to the file and add ?inline=true to the URL, it renders as text, and does NOT display as anything else
• Open two browser windows, both with the same FCO loaded (user, etc). Delete an associated file in one browser, and then try to click on the deleted file in the view that does not show this deleted yet. It should redirect with a "file not found" message when you try to load that file.
• Audit an asset and upload an image during that audit. Confirm that the audit image shows up in the History tab.

[what-the-diff]

PR Summary

• Added SVG file type icon
  A new icon has been introduced in the Helper.php file representing SVG files, enhancing the user's visual experience when interacting with these file types.

• Modified XML file type icon
  The visual representation for XML files has been updated with a new icon in the Helper.php file, making it more accurate to the file type.

• Deleted 'show_file_inline' and 'generateEncyrptedPassword' methods
  Two methods that lived in the Helper.php file have been removed, simplifying the structure and possibly speeding up the codebase.

• Introduced 'allowSafeInline' method in StorageHelper.php
  A new functionality has been built that checks if certain file types are safe to display inline, hence improving the security of our application.

• Updated UserFilesController.php with 'allowSafeInline' method
  The logic for deciding inline display of files is now using the newly introduced 'allowSafeInline' method, contributing to increased performance and security.

• Adjusted ActionlogsTransformer.php to reflect removal of 'show_file_inline'
  The reference to the removed 'show_file_inline' method has been eliminated from ActionlogsTransformer.php, keeping the code base clean and less susceptible to bugs.

• Refactored file listing in view.blade.php
  The block of code for file listing has been replaced with the new <x-filestable> component in view.blade.php. This has resulted in a code base that is easier to maintain and manage and leads to easier feature development in the future.

• New 'filestable.blade.php' file introduced
  A new Blade component has been added to handle file displays. This feature encapsulates and simplifies the logic for uploading displays, streamlining the experience for developers who work with this part of code.

• App.php refactored for clarity
  The helper entry for StorageHelper has been adjusted in app.php, providing improved clarity and ease of use for developers.

• Replaced old HTML table structure for file uploads
  The previous HTML table structure used for displaying file uploads has been replaced with the <x-filestable> component in various view files, such as view.blade.php, consumables/view.blade.php, and licenses/view.blade.php. This results in a simplified upload file structure and maintains consistency across the different modules of the application, resulting in a cleaner, more maintainable codebase.

• Applied <x-filestable> component for models and users
  The file upload table both for the 'models' and 'users' sections have been replaced by the <x-filestable> component, this enables the code maintainability and readability to be enhanced in these parts as well.

[uberbrady]

This looks GREAT - I love that we have all this duplicated code - most of which I don't think I even noticed since it's in a place that generally doesn't give us too much trouble. And now we shrank it down into something small and simple, and I think that's just wonderful. Spectacular work.

[uberbrady]

This looks really nice. This is my third pass looking through it, and just looking at it, it looks much, much cleaner. I think we need to give it a real, serious QA pass, but then I think it seems really solid, and I love how much cleaner this all is. Really, genuinely, wonderful work.

[uberbrady]

So I guess we're sure that we don't need this, yeah?

[snipe]

Grep told me we didn't.

[uberbrady]

I think there's a way to do this with a Storage:: method which will give you the same results and keep us working OK if people choose S3 or some other storage engine.

[snipe]

Storage:: should be doing that already - that's the point of the facade

[uberbrady]

Route-model binding is an option here, if you wanted it. Might help with the indentation level.

[snipe]

Agreed, but out of scope for this PR

[uberbrady]

Again, you could do R-M-B here - but I could also see not wanting to muck around with the 'shape' of the code too much, so probably a bit of a 'nit' if anything.

[snipe]

Again, that's a different PR ;)