[COOK-3503] Supporting why-run for the bluepill_service LWRP.

This commit implements `why-run` support for the `bluepill_service` LWRP.

I found that on converge, the actions taken by the LWRP (if any were taken at all)
go unreported - this stands out when you run `chef-client` with `-F doc`. 
While the resource is marked as updated and picked up by report handlers,
it isn't clear what changed (did the bluepill-based service reload, or restart?)

I also found that implementing `why-run` support  has the added effect of 'fixing' this - 
it causes the actual actions taken by the LWRP `bluepill_service` to 
be reported during a converge:

To illustrate, assume we have in a `foo` cookbook something like:

```ruby
# Keep some foo daemon running - with bluepill

template '/etc/bluepill/foo.pill' do
  source 'foo.pill.erb'
  notifies :reload, 'bluepill_service[foo]'
end

bluepill_service "foo" do
  action [:enable, :load, :start]
end

# we want to restart foo when this file changes.
template '/etc/foo.conf' do
  source 'foo.conf.erb'
  notifies :restart, 'bluepill_service[foo]'  
  # bluepill_service[foo] properly restarts if this file changes,
  # but this fact isn't clearly reported.
end
```

Assume we do a converge and the contents of `foo.conf` are updated. In either case, `bluepill_service` is properly restarted as expected, but this fact isn't clearly reported:

(without why-run support)

    $ chef-client -F doc
    # .. output ...
    Recipe: foo::default
      * bluepill_service[foo] action restart
        (nothing!)

(if why-run were supported )

    $ chef-client -F doc
    # .. output ...
    Recipe: foo::default
      * bluepill_service[foo] action restart
        - restart bluepill_service[foo]