Description of the issue/feature this PR addresses:
This PR addresses an issue where, in the credit card journal configuration form (for either Incoming Payments or Outgoing Payments), users are unable to add a new payment method.

Steps to reproduce the error:
1. Open the credit card journal configuration form.
2. In either Incoming Payments or Outgoing Payments, delete the default manual payment method.
3. Attempt to add either the deleted payment method or a new one.

Video: https://drive.google.com/file/d/1CnghnPyfn90xIv5TZiU8PVyMatX7rGt3/view

Current behavior before PR:
The list view of Incoming/Outgoing payments displays a 'no record' label, and users are unable to add either the deleted payment method or a new one.

Desired behavior after PR is merged:
The credit card journal configuration should display all available payment methods, similar to how the bank journal behaves, allowing users to add new payment methods.

I've created a related ticket here: https://www.odoo.com/es_ES/my/tasks/4501396

Thanks in advance! :) 

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

Steps to reproduce:

- Install Discuss, events and contacts app
- Set a partner langage to another langage
- Open the event app and select an event
- Select 'Attendees' in the smart buttons and click on New
-  In the 'Booked by' field, select the partner with the foreign langage
- Save

Current Behavior:
A registration email is created but the body of the email is not translated to the language of the partner

Expected Behavior:
The body of the registration email should be translated in the language of the partner

Cause of the issue:

In order for the translation to happen inside _render_field() the variable 'equality' has to be True
Link 1: https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/addons/mail/models/mail_composer_mixin.py#L180

Because field is equal to 'body' the value of equality is the value of self.body_has_template_value
Link 2:https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/addons/mail/models/mail_composer_mixin.py#L168

self.body_has_template_value is computed by checking if the 'body' attribute of self (self is an instance of mail.compose.message)
is either equal to self.template_id.body_html or tools.html_sanitize(self.template_id.body_html)
Link3: https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/addons/mail/models/mail_composer_mixin.py#L70

In this case, self.body has been computed using html_sanitize(self.template_id_html)
Link4: https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/odoo/fields.py#L2231
so self.body_has_template_value shoud be True

The reason it's False is that when computing the value of self.body (Link4) the method html_sanitize is used with an argument (**sanitize_vals)
which is not the case when comparing self.body to html_sanitize(self.template_id.body_html) (Link3)

As a result self.body and html_sanitize(self.template_id.body_html) are not equal
which makes self.body_has_template_value be False
which makes equality be equal to False
which makes the translation not happening

Fix :

Inside _compute_body_has_template_value() I made the method also return True if
self.body is equal to html_sanitize(self.template_id.body_html,**sanitize_vals)
with santize_vals having the same value as when self.body is computed

opw-4349122

This is a fix-of-fix.

#### Explanation of the first fix

Before the fix abb3194e190abae023ac2d794e631f38945d5f0d the invoice date was controlling the date that appears in the `Fecha` field of the CFDI, except if the invoice date was set to today or was in the future: in that case, the current time would be used.

However, there would be cases where the CFDI would be successfully sent to the PAC but not registered as successfully sent in Odoo because of a timeout or disconnection. In those cases, using the current time is a problem because we will try to retry sending the CFDI to the PAC, with a new time, which would be recognised as a new invoice.

To solve that issue, that fix set the Fecha to always be the `l10n_mx_edi_post_time` which is the time of posting of the invoice.

However, that isn't okay for many Mexican users who expect that the CFDI date must be the same as the invoice date on the PDF (of course, except if the invoice date is in the future).

#### The fix-of-fix (this PR)

To solve both those issues, here is what we do:
- now, the `l10n_mx_edi_post_time` is set when we first try to *send* the CFDI (rather than when we post it), and then stays the same unless the invoice is reset to draft (which ensures that if we must retry several times to resend the CFDI, the sending time won't change).
- if the invoice date is older than the `l10n_mx_edi_post_time`, it will be used as the CFDI's Fecha. This ensures that users can control the Fecha using the invoice date. If the user modifies the invoice date, they will need to reset the invoice to draft, so the `l10n_mx_edi_post_time` will be reset too.

task-none