Restore previous states from HA after node restart for assumed covers, climates

**Describe the problem you have/What new integration you would like**
Components relying on the unidirectional nature of IR and RF remote controllers (like [IR](https://esphome.io/components/climate/ir_climate.html) or [Custom](https://esphome.io/components/climate/custom.html) climate, or [Time Based](https://esphome.io/components/cover/time_based.html) cover with switches or [RF Bridge](https://esphome.io/components/rf_bridge.html) have the problem that after the node restarts/power cycles, the assumed state is lost (overwritten with incorrect values) in Home Assistant. This is very inconvenient, as in 99% of the cases the states are kept on track correctly by HA, while a reboot of the node just deletes this, overwriting it with incorrect default values.

For the majority of such assumed cases the source of truth should be kept in HA, as that also has built-in state restore even after HA reboot.

**Please describe your use case for this integration and alternatives you've tried:**
- Covers can be worked around with a [Cover Time Based](https://github.com/nagyrobi/home-assistant-custom-components-cover-rf-time-based) Custom Component where HA stores and always restores the last known (assumed) state, the downside is that the the time-based calculations are done in HA and not in ESPHome, lots of scripting has to be done, while ESPHome is just a raw codes transmitter.
- Climates can be similarly worked around with [SmartIR](https://github.com/smartHomeHub/SmartIR) Custom Component where HA stores and always restores the last known (assumed) state of the climate, including modes, target temperatures etc. Similarly the downside is that ESPHome degrades to be used as a simple IR blaster and some of the climate functionality is lost because of SmartIR limited capabilities (not all modes usable, no swing fan etc).
- Another workaround is to create dummy `input_number` and `input_text` entities in HA, and create lots of little automations to sync covers/climates/etc various attributes to these, every time they change. And create another set of automations triggering when coming back online to sync these back to the original ESPHome entities. Downsides are that lots of dummy stuff needs to be created in the system and manually kept track of things; and when syncing back from the dummy entities to the actual entities, these are considered as real commands, and signal is being sent out which may not be desirable in such cases.

**Additional context**
**Proposed solution:** When `assumed_state` is `true`, if node disconnects, in HA don't clear the states of the entities. Eventually just simply don't make the related entities unavailable in HA while the node itself is unavailable. After the ESPHome node boots and reconnects, last known values could be read back from HA through the API.
Time Based cover already supports `assumed_state` setting, IR and Custom or other covers need to be extended with it.

The request covers assumed-state handling for Time Based covers, IR and Custom climates, and RF Bridge integrations, with Home Assistant disconnect/reconnect behavior and API state restoration as the proposed direction. No repository files, tests, or concrete entry points are named, so first identify where assumed_state and entity availability are handled; done means restoring the last known values without sending unwanted commands.

Written by the indexing model from the issue text.