### Description of the issue/feature this PR addresses:
-------
In this commit, the flexible working hours (flexible contract) has been reworked in the resource calendar and the contract.

1. Definition of Flexible working calendars:
Flexible working calendars are defined by setting the `flexible_hours` field to True in resource calendar. Flexible resource are able to set the number of working hours per day freely, without referring to working intervals (attendance).
Added a helper function `is_flexible` in resource for readability and better maintenance of this definition.

2. Introduction of Fully Flexible working calendars
Fully Flexible working calendars are defined by not setting any value to the field `working calendar` in the resource/contract view. This type of flexible calendar has no limit to the working hours per day. This allows to have fully freedom on the length of shifts for resources. Note that for contracts, fully flexible can be selected only if the contract's working entry source is not 'working schedule'. A helper function `is_fully_flexible` is added in resource for readability and better maintenance of this definition. 

Other changes:
- Introduced `flexible_hours` field in resource calendar.
- Reordered resource calendar view field's order.
- In contract, resource_calendar no longer a required field.
- Demo Data added with fully flexible working calendar (Suman Oza)
- hr_attendance: if no calendar (=fully flex) refer to resource's timezone instead of calendar's tz.
- hr_attendance: Adapt calculation of max_hours for hr_attendance gantt view for flexible employees.
- Several tests added

Task-3762895

related PR
enterprise: https://github.com/odoo/enterprise/pull/58599

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

TLDR
====

A payment doesn't always generate a journal entry anymore, it will only do so if an outstanding account is set.

Purpose
=======

Payment management in Odoo should be treated as an extra-accounting process and should not generate accounting entries automatically. Recording payments is primarily used to prevent duplicate payments of the same invoice and to prepare bank files, such as SEPA Credit Transfers. However, it is common for payments to be canceled, rejected, or deleted due to errors, such as insufficient funds in the client’s account or forgotten file submissions.

Another goal of this simplification is to make bank reconciliation easier. The process involves simply identifying the partner and, if possible, matching a document. If immediate matching isn’t feasible, it’s not a problem; you can associate the bank transaction with the partner’s account and complete the matching later. This approach minimizes errors and greatly simplifies the workflow. Currently, the procedure is more complex, often requiring matching within the outstanding account or directly with the partner, which increases confusion and the risk of mistakes (in cases of payments).

Currently, the accounting entries generated by payments can clutter the customer and vendor balances, making data interpretation more challenging. For example, instead of seeing only the invoice entries related to bank transactions, users often see payment entries, which complicates management.

Dates are also an issue, as we often see the payment date, but ultimately, only the bank date is truly useful.

Implementation
==============

Before the payment used to be a composition based inheritance (a.k.a. `_inherits`) of the journal entry, but the journal entry doesn't always exist anymore, we can't rely on that mechanism anymore.
* Payments can be generated from scratch (the "New" button), in that case, the payment will generate it's journal entry upon validation, if and only is there is an outstanding account set.
* Payments can also be generated from various other sources (i.e. "Register Payment", from Expenses, from the PoS,...). In those cases, the source is responsible to generate the journal entry and link it to the payment. By simplicity, the lines to be created can be provided to the create values. In these case the payment won't go through the draft state.
* This also means that there is no synchronisation anymore between the payment and the journal entry.
* Because there isn't always a journal entry anymore, we needed to add some fields on the payment which might be duplidated on the journal entry if there is one: Sent, Memo, Name and State.
* Now that the payments can not have a journal entry, it is impossible to rely only on the reconciliation mechanism to link the payments and the invoices. New many2many fields `invoice_ids`/`matched_payment_ids` have been added between the two models.


Details
=======

* There is now a "(Un)Block Payment" button on the invoice in order to prevent registering a payment if needed.
* When an invoice is fully reconciled (with a bank transaction), the related payments will be marked as Paid. More and improved heuristics will be added in the future to avoid keeping pending payments as In Process.
* Payments without journal entries don't appear in the paid amount, but information about pending payments will be added in the future on invoice reports and the followup.
* New states have been added on the payment. Posted is renamed in To Process, and 3 completely new states are added: 
  * Paid: there was previously a checkbox Matched, but that was only relevant for reconciliation, which is not possible anymore 
  * Canceled: the user doesn't want to proceed with this payment anymore 
  * Rejected: the payment was rejected by the payment provider (insufficient funds, wrong details,...)
* Internal Transfers have been removed: it should be matched as a writeoff during bank reconciliation instead.

[task-4180163](https://www.odoo.com/odoo/project.task/4180163)

### Description of the issue/feature this PR addresses:
-------
In this commit, the flexible working hours (flexible contract) has been reworked in the resource calendar and the contract.

1. Definition of Flexible working calendars:
Flexible working calendars are defined by setting the `flexible_hours` field to True in resource calendar. Flexible resource are able to set the number of working hours per day freely, without referring to working intervals (attendance).
Added a helper function `is_flexible` in resource for readability and better maintenance of this definition.

2. Introduction of Fully Flexible working calendars
Fully Flexible working calendars are defined by not setting any value to the field working calendar in the resource/contract view. This type of flexible calendar has no limit to the working hours per day, as well as on the week. This allows to have fully freedom on the length of shifts for resources. Note that for contracts, fully flexible can be selected only if the contract's working entry source is not 'working schedule'. A helper function `is_fully_flexible` is added in resource for readability and better maintenance of this definition.

To allow these changes, we also introduced changes in the following modules:

**hr_payroll:**
- `resource_calendar_id` field no longer required for hr_contract. 
- in demo data, added `resource_calendar_flex_40h` for flexible contract with a limit of 40hours/week.
- update existing flexible contracts in demo data. (previously, flex contract had their `calendar_id`=False)

**planning:**
- demo employee added with fully flexible working calendar (Suman Oza)
- Adapted numerous methods for calculation of slots duration: whenever the calendar attendance is referred to calculate availability, we set an exception for flexible resources.
- Auto plan: adapted to **exclude** flexible resources for this feature.
- `_copy_slots` method is re-adapted for missing calendar of fully flexible resources.
- progress bar adapted for fully flexible resources: the total working hours of the resource (in the planning view's interval) will be displayed.
- progress bar adapted for flexible resources: the progress bar will be displayed as before in the gantt view. However the denominator will be an approximation in the case of month/year interval, since we cannot know how many working days there are per week.
- Added tests for flex and fully flex contracts.

**planning_contract**: 
- a slot outside the interval of an ongoing contract period returns 0 allocated hours for flexible and fully flexible contracts.

**hr_attendance_gantt:**
- when retrieving unavailable_intervals_by_calendar for fully flex we return an empty Interval to set no unavailability.

**hr_work_entry_contract_attendance:**
- for fully flexible resources, refer to the timezone of the resource instead of the calendar.

Additionally, a demo user with a fully flexible schedule has been added to display the features and facilitate future testing.

Task-3762895

related PR
community: https://github.com/odoo/odoo/pull/157577
update: https://github.com/odoo/upgrade/pull/5851