Implement basic `create` operation for instances

This wires up enough logic to allow instances to be created by node_gce: while
slightly limited in capabilities, it is sufficient to create an instances from
a stock or custom image using non-persistent local disk.

There are limitations:
 * no persistent disk support is yet available
 * networking is hard-coded to the `default` network
 * networking is hard-coded to use an ephemeral external IP

For all that, it provides mediated instance creation.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement `delete` operation for instances

This completes the basic set of functionality available to GCE instances: we
can now delete them, removing the associated data and virtual machine.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement `user` action to manage ssh key metadata

The GCE supplied images allow use of "metadata" on the instance to manage user
accounts; the `sshKeys` field is used by on-node software supplied in the
Google instances to keep a set of user accounts and their SSH keys in sync.

This provides an interactive mechanism to manage that structured data, adding
and removing users and their keys from the list.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement SSH key / account support at create time

This uses the `--login` and `--key` options that mirror those of the `puppet
node install` action to configure a single account at VM creation time.

As with other user management, this is implemented by setting the `sshKeys`
metadata item which is then used by software supplied by Google to create the
account and configure the SSH keys in place.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Move create operation in the file

This moves the implementation of create to a location next to bootstrap -- the
better to make visible the commonalities between them.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Extract common options into a procedural library

Because the design of faces makes it impossible to use conventional OO
solutions, such as inheritance or augmentation of classes, to solve the
problem of identical behaviour across disparate objects, we hit some
challenges when our actions share behaviours in the form of options.

This addresses that the same way the rest of the Cloud Provisioner code does,
by extracting the common options into a shared library of procedural code that
can be used to share execution and, by side effect, behaviour.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Extract "payload" options from other CloudPack install options

The original CloudPack design mashed together a pile of things into what it
called the "install" options -- which, unfortunately, included both some of
the payload options for installation and some of the authentication options
for how to connect to the target system.

This made it impossible to use that single original set of options with GCE,
since the security model is different enough to pose an unsolvable conflict.

This splits out those options into two components, installation and payload;
we only use the later in GCE, and retain the original definition of install
options for other 'clients' of CloudPack.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement bootstrapping of nodes with the GCE face.

This implements the `bootstrap` action, following the pattern of other Cloud
Provisioner faces.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement `ssh` action to help ssh in to instances

The `ssh` action will look up the host details, find a publicly visible IP
address, and then execute SSH to log in to the target machine.  This is a
convenience wrapper over doing the same work by hand.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>