toshiba_acpi: Add support for bluetooth toggling through rfkill

As requested by Henrique, I have reworked this patch against wireless-testing and it uses the new-style rfkill API and to report the input device as a switch.

I did some digging to try and find a usable gpe event but had only limited success. From another look through the AML, it uses GPE08 for almost everything
- inspecting a bunch of state for each event and then sending notifications on different objects. I couldn't find one for the hardware kill switch itself but I did manage to find one that's emitted when the bluetooth device enters the equivalent of the SOFT_BLOCKED state. This is useful for noticing that the hardware switch has been released, but it also fires on transitions from UNBLOCKED to SOFT_BLOCKED - so I had to try and avoid turning around and unblocking the device! I'm not particularly happy with how I did it (ignore-the-next-event) but I can't think of a better way.

--phil

Can it be used as an event that you just take as a hint to READ the state of the switch? I.e. as "switch may have changed state, you better check" instead of "switch changed state"?

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

I've updated the diff to use force_state instead of get_state. I'm a little unhappy in that it requires poking the rfkill state from the input poll function but that's the only way we know anything changed.

The event handling is still the same as before because I realised that there's no fundamental state I can use to distinguish the two transitions - at the time the event fires, the kill switch is inactive and the bluetooth device is disconnected but we simply don't know where we came from (hard killed or on), so we have to maintain some form of state in the driver and the current mechanism is as good (or bad) as any other.

--phil