Auto detect obstruction sensors

[PaulWieland]

When no obstruction sensors are installed, sec+ 2 doors ignore the discrete close command (see #146). The MQTT firmware does not have this problem because it only uses toggle commands. The toggle command is skipped if the door is already in the desired state, which has the same end result as using discrete commands.

Since the toggle command is always accepted by the door, this PR is designed to detect a low pulse on the obstruction sensor input, and if one is found, assume that the sensor is present. If the sensor is present, use the discrete close command, and if not, use the toggle command instead.

It also will report the obstruction status from the status packet if no sensor is detected.

Much testing required before merge.

[agoode]

Is there any way to continue to read the obstruction from the status packet even with obstruction sensors connected? I prefer to report obstruction that way so that I have a clear idea of what the door opener thinks. (This was useful when I had a bad sensor that was triggering a door re-open but not being detected with the ratgdo obstruction input.)

In my yaml I currently have this to enable obstruction-from-status:

ratgdo:
  input_obst_pin: none

[PaulWieland]

Not really. The obstruction from status is really slow which is why I designed ratgdo to detect from the hardware sensors directly. It needs to be one or the other or you will get conflicting messages as the status update lags behind the actual sensor state.

[agoode]

Seems reasonable. It might be nice to (optionally) expose both obstruction sensors. But I'll assume for now it's one or the other.