Add native WaitConditionHandle resource

Adds a native OS::HeatWaitConditionHandle resource, which works
in a similar way to the CFN compatible one, but with a few changes
to make it simpler to use:
- The data passed is validated less strictly, so we tolerate missing keys
  for any of the data (we just fill in default values)
- A signal passed with no data is assumed to mean success
- There are two convenience attributes which provide a string representing
  the necessary curl call to send the signal (to the native ReST API)

This allows a similarly simple signalling mechanism to the CFN compatible
Handle resource, but with no dependency on the ec2tokens keystone extension
or heat-api-cfn service.

Some usage examples here:
  - https://review.openstack.org/106424

blueprint: native-waitcondition
Change-Id: Ie9b5aeb13bfab5fba55c1a49d1572e0777864b29
Update test_signal to use stub_keystoneclient

Adds an argument to stub_keystoneclient such that it can be used to
clean up the stubbing in test_signal

Change-Id: I5b29b0b2dd764c735aa0da7ee8d40d867c8b4f2f
Allow plugins to specify signal event reason

Currently, we have logic in the Resource.signal base-class implementation
which works out the reason string based on knowledge of some of the
signal-handling resources.  This is invariably going to be fragile, and it
won't work at all with any out of tree or contrib plugins.

So instead, move towards a model where we accept an optional return value from
handle_signal, and use that as the reason string instead.  Since no resources
yet return a reason, maintain the old logic as a fallback path, until this
gets migrated into the appropriate resources.

Change-Id: I45fdf112e6cd050bb1f4111977f653ba6440df02
Partial-Bug: #1340894
Merge "Add native WaitConditionHandle resource"
Merge "Update test_signal to use stub_keystoneclient"
Merge "Allow plugins to specify signal event reason"