Concurrent remote receiver & transmitter on same pin

**Describe the problem you have/What new integration you would like**

I would like to know if it's possible/supported to have a remote receiver & transmitter component on the same pin.

The idea would be to "MITM" an existing device's infrared communications. For example the IR climate component allows to not only control an aircon via IR but also to update its own state from a `remote_receiver`, in such a way that you can keep using the aircon's original remote and have ESPHome's climate component also react to those changes.

Here's an example config:

```
# receives IR codes from the official remote and updates our internal state
remote_receiver:
pin:
number: GPIO16
inverted: true
mode: INPUT_OUTPUT_OPEN_DRAIN
allow_other_uses: true
id: ir_receiver
dump: pronto

# transmits IR codes to control the aircon
remote_transmitter:
carrier_duty_percent: 100%
pin:
number: GPIO16
mode: INPUT_OUTPUT_OPEN_DRAIN
inverted: true
allow_other_uses: true

climate:
- platform: hitachi_ac344
name: "Air conditioner"
supports_heat: True
supports_cool: True
receiver_id: ir_receiver
```

**Please describe your use case for this integration and alternatives you've tried:**

This pattern being officially supported would make integrating into infrared devices such as aircons much easier as it only requires tapping a single wire (the wire/pin from the original IR receiver) and is non-destructive as no original traces are cut.

In contrast, a _real_ MITM with remote receiver/transmitter on separate pins would require splicing the ESP into the IR path, cutting the trace from the original IR receiver.

**Additional context**

There's an existing [discussion](https://github.com/esphome/esphome/discussions/2078) around such a "hack" including some success reports.

However, I have tried this on an ESP32 and got broken behavior where an open-drain pin becomes low (as in hard pull to ground) after the remote_transmitter component is used.

I narrowed it down to the fact that ESP32 uses the RMT subsystem to handle IR communications where as others do it in software - this would explain why the people on that discussion had success; they must've used an ESP8266?

Before raising an issue on the main issue tracker I wanted to check whether this is something we wanted to support and whether it warrants an "official" issue on the issue tracker.

Start by reading the remote_receiver and remote_transmitter components, then trace how ESP32's RMT subsystem handles their shared pin. Done means the same pin can receive and transmit without becoming stuck low, while the climate component still updates from received IR commands.

Written by the indexing model from the issue text.