thread_safe_bus.state (getter) should not use locks

### Problem description
I have a small application that listens on one thread, and may send on another (using asyncio). Before sending, I used to check the hardware state by evaluating the `.state` property. I use the thread safe bus.
However, this leads to long wait phases, depending on _incoming_ messages.

It turns out that getting the `.state` property locks both send and receive locks, whereas `lock_recv` is probably occupied by the listener most of the time, which causes the delays.
in `thread_safe_bus.py`:
```
@property
def state(self):
with self._lock_send, self._lock_recv:
return self.__wrapped__.state
```

### Proposed change

I am not very familiar with thread-safe communication in Python, but derived from my C++ knowledge, the value of the `.state` property is only an _enum value_ and should be _atomic_ anyway, especially when reading.
So from my point of view, I would either just return the value without locks. Or - if any locking is needed for some reason - use a separate state-access-lock that is independent from `lock_send` and `lock_recv`.

### Workaround

I guess checking the bus state before each `send()` call is not the correct way to do. I switched to a mere `send()` and catch a `CanError` exception afterwards, which works fine without delay.