Steps to reproduce [17.0+]:

- Create a website form of any type in which you have:
    - One "Name" or other text field.
    - One field with the "Date" type.
    - One field "Email" with the visibility condition: "Only visible if"
    a field of type "Date" "Is set".

- When you complete the "Date" field, the "Email" one should show but it
does not > It shows if you also add at least two characters to the text
field.

Starting from [1], an OWL date picker component was introduced mainly to
replace the use of `TempusDominus` and `DateRangePicker` libraries.

After this change, an adaptation (from [2]) was done to completely
replace every usage of `TempusDominus` with the new OWL component 
(including the form date[time]picker fields).

One of the lost features from `TempusDominus` was the trigger of an
"input" event on date [time] change, which also triggers the form field
visibility check.

The goal of this commit is to fix this behaviour by simply updating
fields visibility on every component value change.

[1]: https://github.com/odoo/odoo/commit/b5794e89e1ad29e2a86c7ddaf241e3fc24654b5f
[2]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628

opw-3778129

Forward-Port-Of: odoo/odoo#157328

When you create or register a payment, the domain of the payment method lines is based on a computed field dependent of the selected journal. The issue is that the interface isn't blocked when waiting for the onchange return.  So if the user changes the journal, then select the payment method quickly enough while the onchange is still pending, he will be able to select outdated values.

It is a limitation of the js framework, so to avoid the user encoding wrong datas, the fix here is to raise a `ValidationError` telling to re-select the payment method.

To reproduce:
- create second bank journal, with outbound payment method lines having different names than the ones of the first bank journal (in order to distinct them).
- slow down the `_compute_payment_method_line_fields` method
- create a vendor payment, switch the journal to the one created and select the second payment method (before the onchange ends).
- save the payment.

-> The payment has a payment method line from a different journal

opw-3587241

Enterprise PR: https://github.com/odoo/enterprise/pull/56602

Forward-Port-Of: odoo/odoo#157872
Forward-Port-Of: odoo/odoo#147583

<strike>
## [FIX] l10n_mx_edi: Set "CFDI to public" to true for foreign invoices
    
The field "CFDI to public" is currently only set to true in
the domestic to public case (special VAT / Rfc value XAXX010101000).
    
After this commit "CFDI to public" will also be set to true in the
XEXX010101000 case.
    
related: task-3731058
</strike>
A part of the original PR was reverted and left out in 17.0+ (https://github.com/odoo/enterprise/pull/58522)

## [FIX] l10n_mx_edi: import: fix partner creation and detection logic

There are currently the following problems when importing an invoice
with an unknown partner. A new partner is created in this case.
For invoices with an unknown domestic partner (no special VAT values):
- (1) There may be a VAT validation error.
- (2) The "CFDI to public" field (l10n_mx_edi_cfdi_to_public) on the
      invoice will be set to True. It should be False.
For invoices with an unknown foreign partner (no special VAT values):
- (3) The partner is created w/o country or VAT value (since only
      the special VAT / Rfc value XEXX010101000 is used).
      Thus the detection logic applied to the partner to decide
      whether we are in the domestic non-public, domestic public or
      foreign case does not work correctly.

The issues are solved after this commit by the following changes
- (A) The country is set to Mexico for all created partners that are not
      from a foreign invoice (XEXX010101000).
- (B) The detection logic to decide the case is updated.
      Also see (C).
- (C) The "Foreign Customers" fiscal position is set for partners
      created during the import of foreign invoices.

Note on (B) / (C):
We still want to assume that partners without a country are Mexican
partners. This is done since (many) Mexican users will not set an
explicit country for Mexican customers.
(One would e.g. not put the country for domestic letters either.)
This is why we use the "Foreign Customers" fiscal position (C).

### Details

(1)
Due to the missing country the wrong VAT validation is used.
The same error can be reproduced on a runbot when creating a new
customer without country and VAT DEA040805DZ4
(works after setting the country to Mexico).

(2) / (3)
Due to the missing country on the partner the invoice is wrongly
interpreted as a domestic invoice to public (XAXX010101000).
This leads to the wrong "CFDI to public" value.

### task

task-3731058

Forward-Port-Of: odoo/enterprise#58522
Forward-Port-Of: odoo/enterprise#57516

On an IDE (VSCode) with a TypeScript Server.
For some reason, it was not possible to have imports suggestion to OWL in enterprise after commit [1].

Our main hypothesis is that, due to commit [1] who points to odoo/addons, import lines in those files are resolved first in the scope of the odoo directory.

Consider a file in enteprise:
```js
import { registry } from "@web/core";
import { Component } from "@odoo/owl"

```

From the TSServer point of view it needs to resolve `@web` first, which itself has to resolve `@odoo/owl` in its directory scope, that is, in the scope of odoo community. It then keeps it in cache for later and importantly shadows the one present in enterprise/node_modules. Only then the explicit `@odoo/owl` is resolved with the odoo community's owl module from the cache.

Since that owl module from the cache is not explicitly available in enterprise, there are no imports suggestions.

This commit defines a main.d.ts file that only exposes the community's `@odoo/owl` explicitly. This hypothesis is confirmed by some hints that we discover during debugging:
- delete odoo/nodule_modules in enterprise: @odoo/owl becomes a suggestion again.
- comment the path line of @web/* in enterprise/jsconfig.json, owl is suggested.
- replace the copy of node_modules in enterprise by a symlink to odoo/node_modules, owl is suggested. This last one should also be considered as a valid fix for the current issue, as node_modules in odoo and enterprise *are the same*.

After this commit, owl is proposed for imports in VSCode.

[1]: 62cbb20

Forward-Port-Of: odoo/enterprise#58601

## Steps to reproduce
- Install **Payroll**, **Planning** and **Time Off** apps
- Create a new working time of 56 hours per week:
	- Go to **Payroll** app
	- Go to **Configuration** > **Working Times**
	- Create a **NEW** working time -named 56 hours/week- that has 7 days (Monday to Sunday), each from **8:00** to **16:00**
	- Set a time zone of your choice, in my case it Africa/Cairo
- Go to **Employees** app and create a **NEW** Employee -named 56 hours/week employee- with the same time zone as the new working time
- Create a new Contract for the newly created employee:
	- Click on the Contract smart button
	- Click on **CREATE**
	- Set the **Contact Start Date** -ex. 1 Feb 2024-
	- Set the **Working Schedule** to the newly created working time (56 hours/week)
	- Set the **Work Entry Source** as **Planning**
	- Set the state of the contract to be **RUNNING**
- Create a 10 day planning:
	- Go to the newly created 56 hours/week employee
	- Click on the Planning smart button
	- Click on **NEW** to add a new Shift (example values):
		- from 20 Feb 2024
		- to 29 Feb 2024
		- from 8:00 to 16:00
	- Click on **PUBLISH**
- Go to the newly created 56 hours/week employee. Click on the Work Entries smart button. Set the view as _list_. We now have a planning of 10 days totaling 80 hours.
- Create a time off:
	- Go to the newly created 56 hours/week employee
	- Click on the Time Off smart button
	- Click on a day to request a time off -for our example set as 23 Feb 2024-
	- Go to the **Time Off** app > **Approvals** > **Time Off**
	- Remove **My Team** filter
	- Approve the newly created time off
- Go back to the Work Entries of our employee
- Click on **REGENERATE WORK ENTRIES**
- Set the Work Entries in _list_ view
- Notice how the duration of the last work entry is **_incorrectly_** calculated:
	- The 1st entry has 24 hours for 3 days of work (20 Feb, 21 Feb, 22 Feb) which is CORRECT
	- The 2nd entry is for the time off having 8 hours for 1 day (23 Feb) which is CORRECT
	- The 3rd entry has **24** hours! although it's for 8 days (24, 25, 26, 27, 28, 29 Feb) totaling **48** hours. There are **24** hours difference (3 days), which actually (3 holidays in my case)

## Investigation
#### First, let's see how we reach to recalculating the duration (allocated hours) of the planning slots:
- When the work entries are regenerated, the slots durations are recalculated via `_get_duration_batch()` https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/hr_work_entry_contract_planning/models/hr_work_entry.py#L43 more precisely  `_get_planning_duration` which recompute the durations by creating new temporary planning slots -notice how we didn't pass the `resource_id` of the slot-https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/hr_work_entry_contract_planning/models/hr_work_entry.py#L29-L36 passing the values from the original slot but the new start and end date.
- That triggers `_compute_allocated_hours()` https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L239 
#### Second we'll examine three cases:
1. What if the slot has no resource_id ? (This is actually the issue specific to the ticket, the `resource_id` is not passed)
	- the `planning_slots` will be empty, while the `slots_with_calendar` will have our respective slot which triggers the `if slots_with_calendar:` block https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L242-L248
	- As we have no resource, we fall back to the `company_id.resource_calendar_id`  which is the standard 40 hours/week https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L269-L271
	- We then go into `_get_working_hours_over_period()` which will use the `company_id.resource_calendar_id` as it has no `resource_id` https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L1677-L1679
2. What if the slot has a resource with `flexible_hours = False`? Same as 1
3. What if the slot has a resource with `flexible_hours = True`?
	- the `planning_slots` will will have our respective slot https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L242-L248
	- which will trigger this block https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L249-L252
	- going into the `_calculate_slot_duration()` function that has a drawback:
		- The period is a timedelta object https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L1106 that has days (`period.days`) which is the number of full days in that period and seconds (`period.seconds`)
		- if the `period.seconds` is not ZERO that means we have a non-full day.
		- when `max_duration` is calculated we always round up the days by adding 1 https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L1108 even though `period.seconds` can be 0. in that case we should only take `period.days` into consideration

## The Fix:
- By passing the `resource_id` when creating the new temporary slots, we make sure we are dealing with the correct `resource_calendar_id`
- The `_calculate_slot_duration()` modification addresses the issue when `resource_id` has `flexible_hours = True` basically if the employee work with flexible hours

opw-3662389

Forward-Port-Of: odoo/enterprise#58562
Forward-Port-Of: odoo/enterprise#57205