A traceback error occurs when the user uninstalls the model used in the mail template 
referenced in the loyalty program.

To reproduce this issue:

1) Install `sale`, `stock`, and enable `loyalty` from settings 
2) Create a new loyalty record from `sale/product/discount & Loyalty` 
3) Set program type as `loyalty cards` and add `mail template` from `communication`
4) Open the selected mail template and change the model to the `stock lot` 
5) Now uninstall the stock module and open the above loyalty record 
6) From the `Loyalty Cards` stat button create a record with a partner

Error:- 
```
KeyError: False
```

We used the `stock lot` in the mail template. However, when the user uninstalls 
the `stock` module, the value of `model_id` will be set to `False` in that mail template, 
which leads to the traceback mentioned above from the code below.

https://github.com/odoo/odoo/blob/28815810d9835772aa2fbe72339360f0771634a9/addons/mail/models/mail_template.py#L574-L575

We can resolve this issue by applying `ondelete` equals to `cascade` on `model_id` and 
`template_id` of the `mail_template` and the `loyalty_mail` respectively. 

As the model is deleted, `mail template` and `loyalty mail` must also deleted

Note:- 
We already solved a similar type issue from this PR https://github.com/odoo/odoo/pull/180307

sentry-6088927895

### Steps to reproduce:
- Activate developer mode
- Install the 'l10n_ec' module and switch to an Ecuadorian company
- In Settings > Technical > Database Structure > Decimal Accuracy change the number of decimals for "Product Price" to 4 for example
- In Accounting, create a new Customer Invoice
- Select 'Instituto Ecuatoriano' as Customer
- Add a line with a price with 4 decimals
- Select 'Sin utilization del sistema financiero' as Payment Method
- Confirm
- On the blue popup at the top of the page, click 'process now' to get the XML in the chatter
- In the XML the "precioUnitario" field only has 2 precision digits, it has been rounded
- When adding a discount of 100% this field has all precision digits needed

### Cause:
The price_unit is calculated differently if the discount is 100%. The "precioUnitario" field should always have the number of precision digits specified in the settings.

### Solution:
We need to find the unit price without the discount, but without the included. This value is not computed.
As the values computed in the account.move.line are already rounded based on the currency (2 digits) we need to
recompute the values using `compute_all` and multiplying by the `price_digits` to not round in `compute_all`.

The way the rounding is made here is by taking the decimal precision from the settings and making it a power of 10 in `price_digits` (4 decimals results in price_digits = 10000). Then we compute the taxes with `price_unit * price_digits`. As, per definition,  `price_unit` has the number of digits used in the calculation of `price_digits`, we end up with an integer. But after the results of `compute_all` may no longer be an integer. We need an integer to keep the decimal precision. This is why, in the result, there is a call to `round()`.
The call to `float_round()` is to make sure there are not more decimals than 6. This is needed as the number displayed in the XML will always be of 6 decimals, so if the client set a number of decimals greater than 6, it will be rounded in the XML but not on the invoice. To ensure that both values are the same, we round the value here.

Some tests had "precioUnitario" with strange values that did not match the actual price_unit. It was because the precedent way to calculate this field was not perfect, I guess.

opw-4120341

Forward-Port-Of: odoo/enterprise#68555