feat: add version subcommand

[yitsushi]

What this PR does / why we need it:

The version subcommand without any flags prints out a general version
information, good to check what version we have.

❯ ./bin/flintlockd_amd64 version
flintlock v0.1.0-alpha.1-11-af7a1a9

The version subcommand with --short flag prints out only the
version, useful for scripting.

❯ ./bin/flintlockd_amd64 version --short
v0.1.0-alpha.1-11-af7a1a9

The version subcommand with --long flag prints out a detailed version
information, useful for bug reports.

❯ ./bin/flintlockd_amd64 version --long
flintlock
  Version:    v0.1.0-alpha.1-12-gaf7a1a9
  CommitHash: af7a1a9
  BuildDate:  2021-11-03T11:38:43Z

== Why a subcommand and not a -v or -V flag?

Because it can be confusing. Some applications are using -v for
version, some are using -V for version because -v is the verbose
flag. Go, kubectl, and Helm follows the same logic, they have a
version subcommand.

Different flags

• I find it annoying to parse version information from version
  subcommands all the time when I want to automate something, that's the
  --short.
• I find it useful to print out everything we have for debugging or
  filing bug reports, that's the --long flag.
• I find it useful to print out the package/application name, so even if
  the binary was renamed I can see what is the name of the application,
  but without extra information like commit hash or build date. That's
  the no-flag option.

Moved the log.Info call

In general, it's useful to print out the info log on run and gw, but
not for version.

Which issue(s) this PR fixes:
Fixes #163

Special notes for your reviewer:

Checklist:

• squashed commits into logical changes

[jmickey]

I prefer the version subcommand rather than a flag, and it remains consistent with other CLIs in our ecosystem, like kubectl. So 👍 from me.