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

[CyanVoxel]

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:
[...]
Assuming that this is accurate, this could also serve as a starting point for the updated MVC docs

That's pretty much correct, with the exception that the views/layouts should have little to no logic in them, acting purely for arranging and styling the interface elements. Any logic for modifying the view should be on a controller, even if it's a base controller that other controllers are expected to inherit from. There might be exceptions to this if a method really really makes sense to go in a layout, but as a rule of thumb I'm trying to separate all logic from them to have a stricter separation that makes the codebase more flexible (see 9780d68 on a future branch where I'm able to axe the TagSearchPanelView and FieldTemplateSearchPanelView classes, and likewise did not need equivelents to those here for the SuggestBox).

Here SuggestBoxView is a great example of that, just a single __init__() method that constructs the layout and applies styles. The base controller class SuggestBox then sets a SuggestBoxView as its layout and establishes the methods for modifying and updating the layout - this hard separation also allows for other base controller classes to come in and work with the view differently, if ever needed. Classes that extend from SuggestBox like TagSuggestBox and FieldSuggestBox then can take advantage of the base logic for the view while adding or overriding their own, where needed.

More examples of this can be found in 9780d68, where I do that same hard logic splitting in the SearchPanel classes and end up cutting 4 entire classes all while further decoupling the views from the widgets/controllers.

---

I can get some updated docs on all this soon. I've been working ahead with some house-of-cards branches and really putting this paradigm to the test across a lot more of the UI codebase and so far it's been going (unbelievably) smoothly, so I'm feeling very confident about the whole approach.

[Computerdores]

Here SuggestBoxView is a great example of that, just a single __init__() method that constructs the layout and applies styles. The base controller class SuggestBox then sets a SuggestBoxView as its layout and establishes the methods for modifying and updating the layout - this hard separation also allows for other base controller classes to come in and work with the view differently, if ever needed. Classes that extend from SuggestBox like TagSuggestBox and FieldSuggestBox then can take advantage of the base logic for the view while adding or overriding their own, where needed.

Ah, so the goal is to make it possible to switch out the view while keeping the controller and only methods that aid that should be added to the view?