Store AccessKey secret_key in resource data

Similar to the change for SignalResponder, store the secret key
encrypted in resource data, rather than requesting it from keystone
every time the user requests the SecretKey attribute.

Unlike SignalResponder (which stores the signed URL after using
the keypair to sign the request), we need this to be backwards
compatible, to cope with upgrading heat with stacks in the DB
which contain the AccessKey resource but don't have the secret
stored.

blueprint: instance-users
Related-Bug: #1262177

Change-Id: I92826a6dc028b151d98c0a5e2f6ec27db4b744b9
heat_keystoneclient revise get_ec2_keypair

Modify get_ec2_keypair so it's no longer making assumptions about the
number of keypairs a user has, instead we provide create_ec2_keypair,
which just creates and returns a keypair, and get_ec2_keypair just gets
a specified keypair by user and access key ID.

It's now up to the calling resources to manage the lifecycle of the keypairs
(which they should be doing anyway..).  Also make the user_id optional.

Change-Id: I28aa0c2d764b9e957302269598a5910346363d0f
Related-Bug: #1089261
blueprint: instance-users
Merge "Store AccessKey secret_key in resource data"
Merge "heat_keystoneclient revise get_ec2_keypair"