[#68989754] Add vcloud-login utility for session tokens

As described by the --help argument:

    Usage: ./bin/vcloud-login [options]

    Utility for obtaining a Fog vCloud Director session token. It will output a
    shell `export` command that can be consumed with:

        eval $(FOG_CREDENTIAL=example ./bin/vcloud-login)

    It requires a Fog credentials file (e.g. `~/.fog`) with the host and user
    set, but the password set to an empty string. The password can either be
    entered interactively or piped in, for example from an environment variable:

        printenv PASSWORD_VAR | FOG_CREDENTIAL=example #{$0}

This should serve to consolidate the various scripts other teams have needed to
create in order to follow the advice about not storing plaintext passwords in
the fogrc file.

---

I'm going to deal with preventing plaintext password use in a separate PR - but we might as well bundle them both in the same release.

/cc @annashipman @mattbostock 
> This isn't quite right... the following line obtains a session token and exports it as an environment variable. We could either say 'obtain a session token then export it as an environment variable' and then 'you can do this all in one go'; or we could just skip straight to evaling the statement but explain better what it does.

Yep, will re-word.

> Are there any side effects from doing this we should think about? Any reason why one might want to obtain the token and then export it another way? If not, should we think about making the actual command do the exporting? And is there a way we can think about combining the two things so you don't need to do one then the other but one wraps the other?

Unfortunately a child process can't export variables into the parent process's environment. The only alternative is for it to act as a wrapper by executing another command (or the same shell), like one of the ways that you can use `ssh-agent`:

>> There are two main ways to get an agent set up: The first is that the agent starts a new subcommand into which some environment variables are exported, eg ssh-agent xterm &.  The
>> second is that the agent prints the needed shell commands (either sh(1) or csh(1) syntax can be generated) which can be evaluated in the calling shell, eg eval `ssh-agent -s` for
>> Bourne-type shells such as sh(1) or ksh(1) and eval `ssh-agent -c` for csh(1) and derivatives.

But my brief experiments with that proved to be more trouble than it was worth. So it will always need to be run with `eval` or the resulting `export` statement copy/pasted.