[Feature Request]: Replace Fields with Tags (refactor)

[Math-Bee]

Checklist

• I am using an up-to-date version.
• I have read the documentation.
• I have searched existing issues.

Description

Fields are functionally and structurally very similar to tags. While there are some major differences between the two, most of the current field functionality can be replicated using tags (ex: field titles -> category tags), with the other aspects being either undesirable of fields (ex: no field search, no user custom titles) or planned/requested of tags (ex: tag datatypes)
Additionally, fields can end up taking a lot more space than tags: If I were to add an Artist field with the text "John Doe" to 1 entry, that would total 5 cells, whereas using a John Doe tag and an Artist category tag would take 20; However, if I added that same data to 10 entries, the fields would use 50 cells while the tags would only use 40, since adding a new tag-entry relationship is cheaper than adding a new field; With 100 entries, that's 500 cells for fields and 220 cells for tags. I've actually tested this on a couple libraries and the tags seem to use 1.35-2x less space than the fields, although the difference is more apparent & consistent with a large amount of entries

Solution

If fields were to be entirely replaced with tags, the codebase & database would be decently simplified & reduced, and fields would "gain" a lot of missing functionality. There are about 5 things that need to be done to make this happen:

1. Tag datatypes - A new type or datatype column (text, not foreign key) would be added to tags; The tag datatypes would match the field datatypes, so TEXT_LINE (default), TEXT_BOX, DATETIME, and potentially URL. The field titles (Title, Author, Description, etc) would be saved as category tags, ideally at reserved indices like 100-200 or 500-600. Users should also be able to filter tags in the Tag Manager based on their datatype
2. Method to quickly create/add/replace tags - Current fields allow metadata to be added via typing, which is quite useful, and should be ported over to tags. Notably, editing a field is equivalent to replacing a tag. This method would probably replace the "Add Field" button, but if something else replaces the button, it should be added as a tag click action. I'm not entirely sure how exactly this method should be implemented, but 2 ideas are:
   1. Similar modal as fields, but functioning more like a search of your tags
   2. Within the tag search box in the tag search/manager panel
3. Auto-delete function - Without automatically deleting unused tags, the quick-tagging method would produce a lot of "typo tags" - tags created & added that are then quickly removed, never to be used again. However, immediate automatic deletion shouldn't be the default behavior of all tags as it would very likely result in data loss. I have a couple ideas for this too:
   1. Macro to view and delete all unused tags except the built-in ones
   2. Property which deletes the tag if it becomes unused, on by default for certain tag types or tags that are created using quick-tagging
   3. Table to house unused or auto-deleted tags, like a sort-of Recycling/Trash Bin
4. Hidden from Tag Manager/Search Property - Mainly a QoL feature, but a much needed one; There are going to be plenty of previously-field tags & quick-added tags that are used once & never again (Comments, Date Created, etc). The easiest way to implement this is exactly like the is_hidden property but for the "Add Tag" & "Tag Manager" panel
5. Turning fields into tags - All currently existing fields would need to be turned into tags, their corresponding field titles would be turned into category tags if they aren't already, and the value_type & x_fields tables would be either deleted or deprecated. If deleted, this would almost certainly cause a new major version of the database schema, and so should ideally happen with other breaking changes to the database (like tag overriding or deleting preferences)

Alternatives

Implementing all the missing functionality of fields would solve some of these issues, but not fields taking up more space, and extra work would be required to implement anything between fields and tags or anything field-specific.