Time-Based Cover - calculate interlock_wait_time to open/close duration + add max_duration

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

**Usage-Info:**
Time-Based Cover for roller shutter (Rolladen) is used.
To prevent my roller shutter motors against blowing up, I implemented interlock + interlock_wait_time. As far as I understood from ESPHome docu, this is more or less taking care that the motor will not be feeded in both directions similutaniously..
Relevant config:

````yaml
output:
- platform: gpio
pin: ${open_relay}
name: "Relay #1"
internal: true
id: relay1
interlock_wait_time: 350ms
interlock: &interlock_group [relay1, relay2]
restore_mode: always off

- platform: gpio
pin: ${close_relay}
name: "Relay #2"
internal: true
id: relay2
interlock_wait_time: 350ms
interlock: *interlock_group
restore_mode: always off`

````

**Issues / Challenges**:
- It seems that interlock_wait_time is not taken into account by the time-based cover calculation.
Each time the motor stops and starts the 350ms (interlock_wait_time) are not considered in the time calculation. With other words the roller shutter will not fully close/open, if it was previously stopped and started.
- Each motor has a kind of delay when start moving after a stop/start, which adds some additional delay
- Each roller shutter has some variable lenght in summer and winter, could have a [freeze protection](https://www.becker-antriebe.com/fileadmin/user_upload/e03_2010_300_545_0_de.pdf) (will not fully open to avoid getting freezed in this position to the house)
- If motors have a build in endstop (mechanical or electronical) I could use config variable in ESPHome: [has_built_in_endstop](https://esphome.io/components/cover/time_based.html#:~:text=Time%2DBased%20Cover,been%20moving%20in%20a%20direction.), if I understood correctly, the motor will be hold on power until a new command is send? Not my prefered solution as my relay would be ON the whole time, but would fix the issue to not fully open or close due to the delays.

**Ideas / Feature Requests**
In regards to reduce the delay issue and have the position be more preciesly:
- "interlock_wait_time" to be considered in calculation for "time passed" in time-based-cover
- a new configuration value:
"move_delay" (optional, time): A best-guess delay whenever the movement of your motor starts. (Here we could even consider two values, "move_delay_up" and "move_delay_down" as down has normally less delay than up...)

In terms of making sure that the roller shutter is always fully opening / closing, even if the calculated position is already reached, the max_duration entry from Endstop Cover would be helpful:
So instead of stopping at 0% / 100% it will run until the time of max_duration is reached.
Of course, this will only work if Build-In Endstops are avaialble, which is the case for most produced roller motors.

Example:
max_duration (Optional, Time): The maximum duration the cover will opening or closing even if the time-based end-position based on close_duration / open_duration (0% / 100%) has been reached.
!!!ONLY activate if your motor has build-in endstops!!!

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

I am having a house with 18 Roller Shutter (german: Rolladen).
Looks like: [Roller Shutter](https://www.wiegand-info.de/sites/default/files/file/Sonnenschutz_Objekt_Rollo%20Referenzen_Haus%201.jpg)

I use a ESPHome flashed Tuya Modul "loratap sc500w" which is nothing more than a dual relay capable of having the 230v (momentary) switches to connect to.

I have two kinds of motors running the roller shutters:
Mechanical and electronical with limit stop. The only difference is the collision detection of the electronical ones.
(e.g. Somfy LT50 [Somfy LT50 Mechanical](https://www.somfy.de/downloads/de/ga_lt50_60_pa.pdf) or [Becker E03 Electronical](https://www.becker-antriebe.com/fileadmin/user_upload/e03_2010_300_545_0_de.pdf)
Both types of motors do have a user-saved end position, so fully open and fully closed where the motor stops driving.

If the "interlock_wait_time" and "move_delay" and "max_duration" is not an option to be implemented in the time-based-cover, I have some options left:
- living with some strange positions or not fully closed roller-shutters
- experimenting with lambdas to always make sure the relay 1 is stopped before relay 2 is started
- Using Endstop Cover with an template Binary Sensor as "open_endstop" and "close_endstop" are required values and I cannot ignore them...

Any help is highly appreciated. Tried to find the time calculation in the sources my self, but I am unable to identify it. So, no clou if my ideas are easy or difficult to be transfered into code. :(

**Additional context**

Not sure if needed, but here is my complete config:

````yaml
substitutions:
device_name: rollstudio
friendly_name: Studio Ost Rollade
open_duration: 16.65sec
close_duration: 15.90sec
ledlinki: GPIO03
open_switch: GPIO04
close_switch: GPIO05
close_relay: GPIO12
reset_button: GPIO13
open_relay: GPIO14

esphome:
name: ${device_name}
platform: ESP8266
board: esp8285

wifi:
ssid: !secret wifi_ssid
password: !secret wifi_pass
power_save_mode: none
# fast_connect: true

# Enable logging
logger:

# Enable Web server
web_server:
port: 80

# Enable Home Assistant API
api:
password: !secret api_pass
reboot_timeout: 0s
ota:
password: !secret api_pass

# Sync time with Home Assistant
time:
- platform: homeassistant
id: homeassistant_time

text_sensor:
- platform: version
name: "${friendly_name} Version"
icon: mdi:information-outline
- platform: wifi_info
ip_address:
name: "${friendly_name} IP"
icon: mdi:ip-network-outline
ssid:
name: "${friendly_name} SSID"
icon: mdi:signal-distance-variant
bssid:
name: "${friendly_name} BSSID"
icon: mdi:signal-distance-variant

sensor:
# Uptime sensor
- platform: uptime
name: "${friendly_name} Uptime"
unit_of_measurement: days
update_interval: 4h
filters:
- multiply: 0.000011574
# WiFi Signal sensor
- platform: wifi_signal
name: "${friendly_name} WiFi"
update_interval: 300s
icon: mdi:signal-variant

binary_sensor:
- platform: gpio
pin: ${open_switch}
name: "Switch #1"
id: switch1
internal: true
on_press:
then:
- lambda: |
if (id(rolladen).current_operation == COVER_OPERATION_IDLE) {
// Cover is idle, check current state and open cover.
id(rolladen).open();
}
else {
// Cover is opening/closing. Stop it.
id(rolladen).stop();
}
#Reset Device
on_multi_click:
- timing:
#six times short
- ON for at most 1s
- OFF for at most 1s
- ON for at most 1s
- OFF for at most 1s
- ON for at most 1s
- OFF for at most 1s
- ON for at most 1s
- OFF for at most 1s
- ON for at most 1s
- OFF for at least 0s
then:
- switch.toggle: reset

- platform: gpio
pin: ${close_switch}
name: "Switch #2"
id: switch2
internal: true
on_press:
then:
- lambda: |
if (id(rolladen).current_operation == COVER_OPERATION_IDLE) {
// Cover is idle, check current state and close cover.
id(rolladen).close();
}
else {
// Cover is opening/closing. Stop it.
id(rolladen).stop();
}

- platform: gpio
pin: ${reset_button}
id: reset_switch
internal: true
on_press:
then:
- switch.toggle: reset

switch:
# Switch to restart the shutter
- platform: restart
id: reset
name: "${friendly_name} Restart"

- platform: gpio
pin: ${open_relay}
name: "Relay #1"
internal: true
id: relay1
interlock_wait_time: 350ms
interlock: &interlock_group [relay1, relay2]
restore_mode: always off

- platform: gpio
pin: ${close_relay}
name: "Relay #2"
internal: true
id: relay2
interlock_wait_time: 350ms
interlock: *interlock_group
restore_mode: always off

cover:
- platform: time_based
name: "${friendly_name}"
id: rolladen

open_action:
- switch.turn_on: relay2
open_duration: ${open_duration}

close_action:
- switch.turn_on: relay1
close_duration: ${close_duration}
#max_duration: 25sec
stop_action:
- switch.turn_off: relay2
- switch.turn_off: relay1

````