refactor: use constants for OSs

[greyscaled]

Inspired from https://github.com/cdr/coder-cli/pull/446/checks?check_run_id=3695106435

[coveralls]

Pull Request Test Coverage Report for Build 1268223903

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 1 of 3 (33.33%) changed or added relevant lines in 2 files are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.03%) to 48.014%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
internal/cmd/configssh.go	0	2	0.0%

Files with Coverage Reduction	New Missed Lines	%
wsnet/dial.go	2	78.02%

Totals
Change from base Build 1237802265:	-0.03%
Covered Lines:	2816
Relevant Lines:	5865

---

💛 - Coveralls

[jawnsy]

It's unfortunate that Go doesn't seem to offer these constants in their code anywhere. It looks like Go themselves use hardcoded string comparisons everywhere: https://sourcegraph.com/search?q=context:global+repo:%5Egithub%5C.com/golang/go%24+%22windows%22&patternType=literal -- given that, maybe it's okay for us to do that too?

[greyscaled]

Personally I think that doesn't sit well unless at least a type (like TS union of strings as a type alias) is defined. That feels a bit like walking on quicksand.

I don't know their reason, but I think it's reasonable we reach for them in our own domain model/application code base. I'd expect there to be some concept of a constant, enumeration or type in other languages when approaching a similar problem. Go sometimes makes odd choices IMO :P