AGE-124: env output format for services

[murrayju]

This adds support for env as an output format. It is only supported on individual service outputs, and other usages will fail with an error.

The output uses the standard PG* environment variable names, to increase the liklihood of being directly usable in .env files.

Like the other output formats, this only controls what is written to stdout. The user is then able to redirect to a file, if so desired.

tiger svc create --free -o env --with-password >> .env

As part of this, I removed the global --output flag, and instead implemented individual flags on the commands that use it. This allowed for more clarity and accuracy in validation around the presence of the env value.

I also noticed that the tiger config show command had a bug in that it was affected by any CLI args (or env vars) passed to it. We really want this to reflect the config in the file (and defaults if unset). I overhauled how this works, and also added options for --no-defaults and --with-env to control the behavior a bit.

[nathanjcochran]

I still have some misgivings about env as an output format, given output is a global config option/flag, and env is not universally valid.

I think maybe we should consider:

• Not allowing env via tiger config set output, since that would break some commands, and I don't think it's likely that users would want to configure the env format globally anyways.
• Getting rid of the global --output flag and replacing it with per-command --output flags. That way, they could support different options and it wouldn't feel as weird (honestly, it's kind of weird that it's a global flag anyways, since not all commands support it).
• For commands that support the --output flag, still falling back to the global config option (the value set via tiger config set output) if not otherwise specified.

Otherwise, I think this largely makes sense. Though I also think maybe we should add support to tiger db connection-string (or a new command, if connection-string feels too weird?) for outputting these env vars, so users can do it later too (not just when initially creating a service).

Left a handful of other mostly-minor comments below.

[murrayju]

Yeah, I'd be happy to get rid of the global --output flag, I don't think it makes sense. @cevian can you weigh in on that?

so users can do it later too (not just when initially creating a service)

It works with tiger svc describe <id> -o env in this PR.

[jgpruitt]

this is awesome!

[nathanjcochran]

I think this is looking great. Major improvement overall 👍.

I did see one thing that I think is a bug, which we should probably fix. The other comments are mostly minor things that would be nice to fix, but could also be improved later.

[nathanjcochran]

LGTM! Thanks for tackling this!