Do not force target-role to Stopped on retry of creation of a primitive

When creating a primitive with the retries attribute (to retry in case
of failure), and when we retry because of another node creating the
primitive instead of this node, the retry actually updates the primitive
instead of creating it. Which is correct.

However, the update will want to set the target-role to Stopped, which
is only something we do on initial creation. This is because the chef
resource was initially created with the "creation" code path, and not
the "update" code path. The result is that the resource is not running
at the end, breaking everything.

So check for this in the "update" code path, and remove the target-role
if it's there.

```
[Thu, 31 Jul 2014 15:11:55 +0200] INFO: Processing pacemaker_primitive[vip-public-cluster-proposal-1] action create (crowbar-pacemaker::haproxy line 15)
[Thu, 31 Jul 2014 15:11:56 +0200] INFO: Creating new primitive resource 'vip-public-cluster-proposal-1'
[Thu, 31 Jul 2014 15:11:56 +0200] INFO: Processing execute[crm configure primitive vip-public-cluster-proposal-1 ocf:heartbeat:IPaddr2 params ip="192.168.126.5" meta target-role="Stopped" ] action run (/var/chef/cache/cookbooks/pacemaker/libraries/chef/mixin/pacemaker/sta
ndard_cib_object.rb line 91)

================================================================================
Error executing action `run` on resource 'execute[crm configure primitive vip-public-cluster-proposal-1 ocf:heartbeat:IPaddr2 params ip="192.168.126.5" meta target-role="Stopped" ]'
================================================================================

Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '1'
---- Begin output of crm configure primitive vip-public-cluster-proposal-1 ocf:heartbeat:IPaddr2 params ip="192.168.126.5" meta target-role="Stopped"  ----
STDOUT:
STDERR: ERROR: vip-public-cluster-proposal-1: id is already in use
---- End output of crm configure primitive vip-public-cluster-proposal-1 ocf:heartbeat:IPaddr2 params ip="192.168.126.5" meta target-role="Stopped"  ----
Ran crm configure primitive vip-public-cluster-proposal-1 ocf:heartbeat:IPaddr2 params ip="192.168.126.5" meta target-role="Stopped"  returned 1

[...]

[Thu, 31 Jul 2014 15:11:56 +0200] INFO: Retrying execution of pacemaker_primitive[vip-public-cluster-proposal-1], 0 attempt(s) left
[Thu, 31 Jul 2014 15:12:02 +0200] INFO: Checking existing primitive resource 'vip-public-cluster-proposal-1' for modifications
[Thu, 31 Jul 2014 15:12:02 +0200] INFO: vip-public-cluster-proposal-1's ip params didn't change
[Thu, 31 Jul 2014 15:12:02 +0200] INFO: vip-public-cluster-proposal-1's target-role meta changed from  to Stopped
[Thu, 31 Jul 2014 15:12:02 +0200] INFO: Processing execute[crm_resource --resource vip-public-cluster-proposal-1 --set-parameter "target-role" --parameter-value "Stopped" --meta] action run (/var/chef/cache/cookbooks/pacemaker/providers/primitive.rb line 88)
[Thu, 31 Jul 2014 15:12:02 +0200] INFO: execute[crm_resource --resource vip-public-cluster-proposal-1 --set-parameter "target-role" --parameter-value "Stopped" --meta] ran successfully
[Thu, 31 Jul 2014 15:12:02 +0200] INFO: Processing execute[crm configure primitive vip-public-cluster-proposal-1 ocf:heartbeat:IPaddr2 params ip="192.168.126.5" meta target-role="Stopped" ] action nothing (/var/chef/cache/cookbooks/pacemaker/libraries/chef/mixin/pacemaker
/standard_cib_object.rb line 91)
[Thu, 31 Jul 2014 15:12:02 +0200] INFO: Processing execute[crm_resource --resource vip-public-cluster-proposal-1 --set-parameter "target-role" --parameter-value "Stopped" --meta] action nothing (/var/chef/cache/cookbooks/pacemaker/providers/primitive.rb line 88)
```
In this modify case, we're missing a call to `deprecate_target_role`.  If we're going to remove misplaced `target-role` attributes (which I think is probably a reasonable workaround for this ugly situation) then we should at least ensure we log a warning about it.  Can you add that?

BTW I checked and AFAICS no barclamp uses `target-role` directly any more, so this should in theory be OK ...