Using 'version-constraint key' instead of 'queue-id' to be more descriptive.
Celery terminology is already opaque to end users, i.e. 'routing-key'
vs 'queue'. Queue is both a noun and a verb, and refers to both Celery's
queue name that receives queued tasks as well as the act of queuing them.

File was being written with "" as key, since variable reference was wrong.

…/github.com/in03/resolve-proxy-encoder into feat/issue-151/improve-version-constraining

…/github.com/in03/resolve-proxy-encoder into feat/issue-151/improve-version-constraining

- moved hefty imports to CLI sub-commands for faster loading time and
quicker UI responsiveness

- queuer checks other workers compatibility against its own
`version_constraint_key` file

TODO:

- get worker queue name from `version_constraint_key` file, otherwise
all locally workers will still be using git-sha mechanism, including self.

- implement `--hide_banner` option globally with Typer

- implement `RPROX_HIDE_BANNER` environment variable

- further test version collision probability

…/github.com/in03/resolve-proxy-encoder into feat/issue-151/improve-version-constraining

Still in a bit of a weird place with terminology here. We have `queue`, `version constraint key` and `routing key`. The choice to refer to the name of the queue as `version constraint key` better reflects application usage and user expectations. "Queue" on its own is both a noun and a verb and we already use the term to describe a module and the process of "queuing" proxies. Some additional terminology changes in code may be necessary at a later date.