Omit top-level sg from VPC launch-options

[mccraigmccraig]

If an instance is placed in a VPC by providing :network-interfaces
options then the top-level security group name munged from the
pallet group name must not be used, or the AWS API will throw an
Exception.

This commit omits the :security-groups key from launch-options
when the node-spec has a [:provider :pallet-ec2 :network-interfaces]
key.

The problem is described in more detail with stacktraces here :

https://groups.google.com/forum/#!topic/pallet-clj/sWu-4IanCW0

[mccraigmccraig]

hmm. this may be ill-conceived... the sg-id should ideally be gotten from the group-spec rather than the node-spec... i will consider further tomorrow

[mccraigmccraig]

ok,

• there doesn't seem to be any provision in the group-spec schema for specifying a security-group-id anyhow
• jclouds/aws uses the same trick of specifying a security-group on the node-spec http://palletops.com/pallet/doc/faq/jclouds-aws/

so, despite specifying the security-group-id on the node-spec possibly requiring that a different version of the node-spec (with a different security-group-id) will be required for each group, this seems to be the way it is currently done

in which context, this PR seems reasonable

[mccraigmccraig]

on further investigation, it seems that pallet-aws uses a tag on instances to keep track of the pallet group that an instance belongs to, so there's no need to specialise node-specs with different security groups, so this PR seems even more reasonable (apologies for my thrashing about : i'm a pallet n00b)