consolidate deployment targets and publish to ghcr.io

[hay-kot]

To Do's

• Inject Meta Tags for Public URLs
• Inject Recipe schema.org compliant script into HTML for Public URLs
• Change GH Actions to Deploy to mealie:nightly tag for unified build
• Remove split docker files and references from docs
• Update documentation to point to new way to deploy (similar to omni)

What type of PR is this?

• refactor
• feature

Closes #2503
Closes #870

What this PR does / why we need it:

This PR aims to

1. Eliminate the need for a frontend server by serving static files from Fast API server
2. Performs server side injections of meta tags to allow for simple SSR by using python to inject the headers for previews and inter-recipe-scraping
3. Remove all docker deployment targets and consolidate into one single container/target

This is currently a proof of concept, I am undecided if I should continue this, or if it's worth the effort.

@michael-genson - What do you think about this idea? Would greatly simplify deployment examples/docs and reduce resource consumption. Unsure if there are other ramifications of removing Nuxt Server from the stack...

Moving forward with PR will re-ping once ready for review

[michael-genson]

So my gut reaction to this is "yup, makes sense". Based on the various discussions in GitHub issues and Discord it seems like most people prefer the "pin latest and use watchtower" method of deployment and this would make that possible again.

To check my sanity I tried to research the opposite - "should I use Nuxt?". These are the main points everyone is talking about:

• Helps start new projects quickly with boilerplate
• SSR/Metadata handling (mostly for SSO) (and other people were quick to say you don't need Nuxt for this anymore)
• Well-defined directory structure (instead of setting up the router yourself)
• More efficient loading with SSR

Honestly everything I read that's pro-Nuxt seems like a pretty small or otherwise workable thing. The only real issue we might want to look out for is page load time, but it's much easier to just work on optimizing that if it's actually a problem. So I say it's worth the effort of removing it.