State parameter

As promised in #264 here is a pull request on which we can debate and improve our FSM.
The real HW state is *guaranteed* to be read if provided by the device implementer. If not we fall back to what we had before, the `_state_value`. One thing which still bugs me is the implementation of [transition](https://github.com/ufo-kit/concert/blob/2f42614fc2843e2d8987c118bf9fc1c7b696963a/concert/base.py#L142-192) because we are still mixing state "checking" and writing the `_state_value`. (I guess this will never be too neat because for one type of devices we need to provide the full transition table and for other we just read what they say their state is). But what we could do is to separate the `transition` which would then only "check" the states, and then we could implement the state saving for devices with no state checking capabilities, like so:

```python
class Device():
    @async
    @transition(source='standby', target='standby')
    @infect(immediate='moving', target='standby')
    def home_something():
        # Here we are in 'moving' state
        time.sleep(10) # long op.
        # At the end we are in 'standby' state
```

The `infect` "infects" our device with the appropriate `_state_value`, hence the name, but that is also a WIP. On the down side, our decorator list would be sometimes longer than the method itself :smile: and the device implementer would need to invoke it all the time, whereas now it is once and for all in the base class. But e.g. there is an `immediate` state which has no use for the devices with real state... What does @matze think about this?

Observation: we cannot (and also couldn't before because of the hard coded `_state_value`) have more state parameters so if we want/need to implement that there will be some additional effort required.