feat(ui/ux): replace "Add Tag/Field" modals with search+create bar(s) with autocomplete

[CyanVoxel]

Summary

This PR changes the functionality of the "Add Tag" and "Add Field" buttons, removing the search modal windows and replacing them with an inline tag search and creation bar. This bar is designed to speed up searching for tags/field templates to add to entries and greatly reduce friction with the tag creation workflow, especially for new libraries. This is intended to cover and enhance most tagging workflow needs, however the option for a persistent dockable search list modal is still planned for the future in order to cover additional workflows that aren't covered by an autocomplete search bar.

Full Features

• Click "Add Tag" or press Ctrl+T to open the tag search/create bar.
• Type to search for the name of an existing tag, or use that search to create and add a new tag right there.
  • Pressing Enter with no results will create a tag from your search query and add it to the selected entries.
    • In the options, or right-click context menu on the search bar, you can toggle the option to open the "Edit Tag" modal after creating new tags if you prefer that extra step.
  • Pressing Enter with one or more results will add the first tag (that's not already on your entries) to your selected entries.
  • Holding Shift while pressing Enter will force create a tag from your search query, regardless of the search results. This is also indicated by the first tag in the results becoming translucent.
• After adding a tag, the "Add Tag" button is now focused, allowing you to press Enter or Space to quickly reactivate the search bar.
• Pressing Esc, pressing Enter with nothing typed, or clicking off of the search bar will exit the search and return the "Add Tag" and "Add Field" buttons.
• All of the above is also true for Field Templates, where the hotkey is Ctrl+L to open its respective search bar.
• New Field templates are automatically edited after being created, since they have a type that must be chosen before they can be used. This is separate from the option to automatically edit a field's contents once a template has been applied to an entry, which is on by default.

Project Layout

Full disclosure, this PR is also trojan horsing in some MVC-related changes that I've been honing in on while developing this. As someone who's been knee-deep in all flavors of the newer UI paradigms we've been using in the project, I've gotten a real good feel for what's been working and what hasn't. Many of the new UI files here ended up spinning off from the search modal/panel classes, which became so heavily modified while I was developing an embedded search that I just split my changes off into new classes. I'd eventually like to go back and retroactively apply the paradigms introduced here into the older classes (and try to reduce code duplication where possible).

The gist of these changes comes down to me using a more traditional MVC setup and tailoring it to Qt's needs, using views as layouts and controllers as final widgets. This solves every problem I've had with the existing MVC guidelines and implementations while meeting the goals set out for the MVC refactor in the first place, all while fitting in cleanly with Qt's widget system. I'm also starting to make some other opinionated changes after working with this part of the codebase so much, like dropping controller from controller filenames and using _single underscore names for private variables instead of using both _single and __double names that were trying to mimic a semblance of private/protected variables in a language that just unfortunately doesn't have that functionality (name mangling doesn't count). In my experience working with the areas of the codebase that had accrued these changes, it's just become way more cumbersome than helpful.

TODO

This PR

• Do the same for "Add Field", or at least make it functional in the meantime
• Fix issue with removing tags not updating the autocomplete while its open
• Update documentation
• Fix tag appearances where they used to be wide

Likely Future PRs

• Refactor search panels to use same MVC paradigm as this, and reuse code where possible
• Allow for tabbing between different autocomplete suggestions
  • with an indicator of which one will be added
• Remove Edit menu "Add Tag to Selected" option (once persistent search panel feature is available)

Closes #1379.

Tasks Completed

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

[Computerdores]

Ok, I've taken a look at the code for the new suggest box to understand the idea behind the MVC approach you have gone for here.
I'll just summarize what I think that idea is and I would ask that you tell me whether I understood it correctly and whether I missing anything important:

• every custom widget class is itself the controller
• the view is the layout used by the widget/controller class
• the controller exposes public methods for the users of the widget to call (in the case of our preview widget, that would be something like show_from_path(path: Path))
• the view/layout exposes public methods for the controller to use to control it (in the same example, that would be something like hide_video_preview, show_video_preview, video_preview (property), and the same for audio and image preview)
• the public controller methods then orchestrate the view to achieve their purpose (in the same example, show_from_path would identify what type of file it is, then hide the wrong previews, show the correct one, and use e.g. audio_preview to get the preview and tell it to show the audio file at the path)
• the view takes care of styling, arranging, and creating the widgets
• generally, if it isn't meant to be called from outside the class it should be prefixed with _

Assuming that this is accurate, this could also serve as a starting point for the updated MVC docs