Spoolman & NFC general architecture for future work #1129

Hi @Donkie, I think this doesn't belong in a PR, but rather here before I submit yet another PR out of the blue.

I've got the OpenPrintTag codec support PR you've seen, but I also have ready similar codec integrations for TigerTag and Qidi tags.
Those I can either submit now or piecemeal one after the other. You choose how you want me to pass that on. But I've structured them so there is an order for submission: first OpenPrintTag codec, then TigerTag codec, then Qidi codec.

Then there's a last PR that I don't know how you will feel about. It's about integrating a TigerTag DB lookup when we read a TigerTag. They have a vendor-certified DB for signed tags, so the code I have uses the info in the tag to fetch the filament data from the TigerTag DB and cache it locally similarly to the SpoolmanDB external filament import system.

The reason for this is that I run my own print farm. I get spool inventory coming in that is not in Spoolman. I have a NFC USB unit on the desk, connected to my server hosting Spoolman. Being able to simply scan tags to create new spools on arrival is essential for my workflow. I suspect it would be similar for many others. So, pulling tag data and adding filaments that don't exist from a verified source (i.e. TigerTag DB, with vendor info), is a good way to do that, from my perspective. What are your thoughts on this? Would this be an ok addition (optionally enabled) in core?

Further, am preparing a companion service that would connect an NFC reader/writer, with the goal being able to automatically lookup a spool from the tag, and if it exists we just bring up the spool ID in the companion UI, and if not, we get a popup about inserting the spool into the DB. I was planning on making this run as part of the docker compose stack, again, optional. I will have the repo for that up shortly, but I was wondering if this was something you would want ownership of, so we could ship a default docker-compose stack that includes the optional service in the stack, but turned off. And then as needed, users can turn the companion NFC service on or off.

The one thing I really preferred about my old integration in #880 was the ability to have the UI buttons trigger a tag read or write of a tag on the server directly, and not having that in core is fine - but I am trying to fill in the feature gap. I am not sure what the best form is, hence this discussion.