## **Issue Before This Commit:**
When a work order is assigned to an employee (not linked to the current user),
and the current user marks it as done, the time log is wrongly created
under the current user’s employee instead of the assigned one.
This behavior caused confusion for the user as the
wrong person was shown as working on the order.

## **Steps to Reproduce:**
- Create an MO with work orders and confirm it.
- Assign another employee to a work order.
- Mark the work order as done with the current user from the work order line.
- Open the workorder and notice that the time log is created for the current user’s employee.

## **Cause of the Issue:**
The bug was introduced in PR (https://github.com/odoo/enterprise/pull/84790),
where the logic for assigning the main employee was overridden,
ignoring the case of an already assigned employee.

## **With This Commit:**
The time log is now created for the assigned employee,
This resolves the confusion by ensuring
the right person is tracked on the work order.

TaskID: 4983514

Forward-Port-Of: odoo/enterprise#100604
Forward-Port-Of: odoo/enterprise#93378

This restores a feature lost at [1]: a call beginning before the
calendar current range but ending inside it was not shown anymore.
Indeed the `end_date` became computed from the `duration` instead of the
other way around, allowing efficient domain manipulation based on the
duration. However, it prevented domain manipulation based on the end
date, which the calendar view needs. It also just makes sense to allow
filtering based on the end date too (even if we judged it less useful
when making [1]). A solution could be to store the end date too, but it
would be redundant data. This instead allows domain manipulation through
a field `compute_sql` definition.

At the same time, this does the same thing for the start date: creating
a new computed field `effective_start_date`, which is either the call
start date or its `create_date`. This allows to entirely remove the
domain override needed in the calendar model (combined with the
community commit that comes with this one, which makes the calendar now
consider records without a set end date but which started within range).

Note: the date_delay option of the calendar was removed at [2].

This also fixes a runbot issue during the "click everywhere" test:
- Enter VoIP app
- Go to calendar
- Enter web studio
=> Crash, because the studio calendar ignores the VoIP custo about the
   calendar domain and filters on `end_date`. The VoIP custo being gone
   and filtering on `end_date` restored, this is not a problem anymore.

[1]: https://github.com/odoo/enterprise/commit/47300cc462420273dd90d5668f542878b6f73254
[2]: https://github.com/odoo/odoo/commit/40c75d3635b4d0de8fca631e4aebd26a466a8709

task-5350495
runbot-234398