Create hardware property

This MR rework the why hardware properties are described.

• Create a HardwareProperty in order to hold everything needed by the control system to read/write a property.

• As result HardwareProperty can handle HardwareTranslation (one property kind by one)

• GetterSetterHardwareObject should also not be needed cause each control system can store custom stuffs to handle a property.

• HWR Shutter is probably broken

I did change the behaviour of get/_get/_do_get (same for set)

• get use abstract hardware values
• _get have to handle the value translation
• _do_get only handle control system values

To discuss

1. I did not implement the _set_{prop} methods. If eveything is fine, we can handle it. Easy to fix.

2. Now we have a proper list of property description, this easily be flattened the following way. I feel like it's convinient to write this way, but it's up to you (there is pro and con)

Actual

class Beamviewer(...):
    property_map = {
        "led": HardwareProperty("led_status"),
        "foil": HardwareProperty("foil_status"),
        "screen": HardwareProperty("screen_status"),
        "diode_range": HardwareProperty("diode_range"),
        "diode_ranges": HardwareProperty("diode_range_available"),
        "state": HardwareProperty("state", getter=_get_state),
    }

Result

class Beamviewer(...):
    led = HardwareProperty("led_status")
    foil = HardwareProperty("foil_status")
    screen = HardwareProperty("screen_status")
    diode_range = HardwareProperty("diode_range")
    diode_ranges = HardwareProperty("diode_range_available")
    state = HardwareProperty("state", getter=_get_state)

3. We could do the same for calls (only if there is no overlap bettween calls and property names)

4. Beamviewer _call_led, _call_diode... could be a dedicated property setter. No need call here. It's also up to you.