refactor: media types rework, dynamically load preview renderers

[CyanVoxel]

Summary

This PR completely reworks the media type system to allow for new functionality such as multiple group contexts, group names and multiple aliases, and dynamic media type registration. This PR also changes how preview renderers are loaded, turning them from functions into classes and dynamically loading them on startup. Preview renderers now handle their own media type registration, further reinforcing this modular change.

Since this diff is pretty large, I'll point any potential reviewers to the following areas:

• media_types.py has completely new code and has been downsized to be just the class logic.
• All file type registrations have been moved to both file_groups.py for the SEARCH context, and inside individual preview renderers for the RENDER contexts. These are largely the same extensions, just grouped and translated to the new system.
• While every preview renderer has been touched, there's no real changes outside of the new explicit media type declarations and an overhaul of the text thumbnail renderer(s).

Media Types

• Media types are now made of atomic FileType objects / one or more extensions associated with one or more contexts. MediaTypeGroups then group these file types into a named groups along with their contexts. Depending on how a group is accessed with a given context, the members of the group may differ.
• Contexts describe to media type groups what extensions are part of a group under a specific context. Currently, there's the "Search" and "Render" contexts, but there may be any number of additional ones added in the future.
  • Adding additional contexts won't change this system, as it's designed to accommodate for any number of arbitrary contexts.
  • A great example for why contexts were needed would be ".ai" files, where when searching they need to be considered as Adobe Illustrator files, but when rendering previews they need to be considered as PDF files. As more discrepancies like this popped up over time, it was clear that the media types system needed to accommodate for this.
  • More than one extension associated with a file type indicates that those extensions are effectively equivalent, such as ".jpg" and ".jpeg". This equivalency persists across all contexts.
• Media types are registered at runtime, allowing for modular behavior and future plugin compatibility.
  • For example, dynamically loaded Preview Renderers can register additional media types using contexts that can add functionality to both the render system and the media type search system.
• Media type groups can have one or more human readable names, which the search system now leverages. While these names aren't translated at the moment, it should be straightforward to add on additional translations for these types in the search system once a procedure for translating these has been established.
• Media type search now has an emphasis on groups and chained groups of media types, with the goal of making media type searching "just work".
  • If you type in "Word", you'll get all Microsoft Word files, like ".doc", ".docx", etc. Same goes for "Microsoft Word", "Office Word", "Microsoft Office Word", etc.
  • If you type in "Office", you'll get all office suite extensions. Typing in "Microsoft Office" or "MS Office" will get you Microsoft Office extensions explicitly, while typing things like "iWork" will get you Apple's, "OpenDocument"/"OpenOffice"/"LibreOffice" will get you those explicitly, etc.
  • Typing "Adobe" will get you all Adobe file, "Photoshop" or "Adobe Photoshop" will get you those explicitly, and so on.
• MIME type fallbacks have been removed. These never were too useful for us, and as our own catalog of file extensions has expanded and been refined, the utility of MIME type guessing has fallen practically to zero.

Preview Renderers

• Class-based to dynamically load at runtime and be called in a simpler loop given a base render() method
• Lays the groundwork for future plugin abilities (could work now, but I don't want to commit to a schema at this time)
• A (sort of out of scope) addition I made is improvements to the default text thumbnails, including a cleaned up font and generic syntax highlighting for markup and code files. This was done to help show some of the new utility in the media types system (and also because the temporary text thumbnails can't get any worse then how they were).
  • This is still just laying the groundwork for more in-depth syntax highlight rules and groups, but I wanted to get this framework in so people can then break off chunks of files from this and clean up the syntax groups over time without needing to figure out the base implementation first.
  • This is also just a system intended for the thumbnails - full text previews in the Inspector panel is still a separate planned feature.

Progress towards #1460

Tasks Completed

• Platforms Tested:
  • Windows x86
  • Windows ARM
  • macOS x86
  • macOS ARM
  • Linux x86
  • Linux ARM
• Tested For:
  • Basic functionality
  • PyInstaller executable