Backport a part of 40da85aab905fd4accf8c01887e62b07537ccd2f.

Make some of the ORM methods private for the sake of correctness and to prevent people from using incorrect RPC calls. We are targeting methods that return recordsets that are not returned in the correct format in RPC. This commit doesn't strictly follow our stable policy, but it's unlikely to break anything.

Small change to the original version: we are not directly modifying odoo.api.call_kw(), as it is used by _eval_xml() and we don't want to change that in stable (or we need to backport part of https://github.com/odoo/odoo/pull/182709).

#### Original commit message

Explicitly prevent calling non-public ORM methods via RPC, without breaking the API

The ORM contains a series of API methods found on Models and recordsets, next to the main CRUD methods. Those utility methods are very commonly used in server-side business logic code, and were historically named without the usual underscore prefix that should mark them as private (e.g. `_private_method()` vs `public_method()`).

Examples:
- the `browse()` method returns a recordset from a list of IDs, which is really just a proxy object prepared for other recordset operations ;
- the `fetch()` and `search_fetch()` methods populate the transactional in-memory cache for a set of fields and record ;
- and many more...

The lack of prefix makes writing business logic code a bit simpler, but causes confusion because these methods look like they are public.

Of course, calling such internal methods over RPC doesn't make sense, and may crash or cause unexpected results.

This commit marks those internal methods and prevents calling them over RPC. This is preferred over renaming them with an underscore prefix, as that would break a lot of existing code without a good reason.

All business logic code must still follow the best-practicce convention of prefixing non-public method with underscores, by default and by design, to avoid mixing different conventions. The `@api.private` decorator is reserved for exceptions for ORM methods.

task-4505030

https://github.com/odoo/enterprise/pull/79382

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

Forward-Port-Of: odoo/odoo#198998
Forward-Port-Of: odoo/odoo#197783

Issue:
------
Case:  User Settings menu is basically used to handle created users but when clicking on the `New` button within the User Settings the form view corresponding to that model i.e; `res.users.settings` will be opened which is an inappropriate behavior.
Whenever a User is created that user will be reflected within that menu. There's no meaning of having `New` button when no user is created to handle.

Solution:
-----------
Some users do not have a user settings yet, so it is a perfectly valid use case to create one.
We should not artificially prevent acceptable behavior in technical/admin menus.

Steps to reproduce:
------------------------
1. Create a database in version 16.0.
2. Go to `User Settings`.
3. Click On `New` button. Try making changes and save.
4. An Invalid Field `User` error will Occur.

This is because there's a many2One field i.e; `user_id` within the tree and form views which is basically an existing user.
The `New` button will open a form view with no User which is a must. And will cause the Invalid field error when trying to save any change.

Ref:
https://github.com/odoo/odoo/blob/16.0/addons/mail/views/res_users_settings_views.xml#L24

Ref Screenshot:
![image](https://github.com/user-attachments/assets/24373b6e-2d67-42f7-9506-24faa3021e41)


Co-Authored By - @seb-odoo

Forward-Port-Of: odoo/odoo#196844
Forward-Port-Of: odoo/odoo#193400

**To reproduce:**
1. Create two branches within a company.
2. Set a bank account linked to the journal defined in the parent company
3. Create one payment, such as a SEPA payment or check, to be batched later, in each branch.
4. Selecting both branches and the parent company, create a batch payment with both payments.
5. The error "All payments in the batch must belong to the same company." is raised.

**Desired behavior:**
The payments in different companies that are branches of a common head office should not trigger the error. They should be allowed to be batched.

**Cause:**
The function `_check_payments_constrains()` in account_batch_payments raises an error if more than one company_id is present in the payments being batched.

**Solution:**
Change the check in `_check_payments_constrains()` to raise an error only if more than one root_id for the companies in the payments is present. This way, payments from several companies, branches of the same head office, can be batched. Payments from companies that do not share the same root_id, however, still raise an error when attempting to batch them.

task-4568317

Forward-Port-Of: odoo/enterprise#79359

**To replicate:**
1. Install a localization reports module (e.g. l10n_lu_reports)
2. Create two branches for the company in the localization: one with a different VAT, and another without VAT (it takes the same VAT as the closest parent with VAT)
3. In Accounting > Reporting > Tax Report
4. Select only the company with a different VAT. The button to export an XML is not enabled.
5. Select the parent company and the company without VAT. The button to export an XML is not enabled.

**Issue:**
In some Tax Reports and EC Sales Reports with branch companies, the additional buttons are not enabled properly, even when all companies with the same VAT are selected.

**Expected behavior:**
If all branches with the same VAT are selected, export buttons should be available.

**Cause of the problem:**
In the tax report handler and EC sales report handler, `_custom_options_initializer()` calls the function `_enable_export_buttons_for_common_vat_groups_in_branches()`, which should enable the buttons if branches with the same VAT are selected.

When extending `_custom_options_initializer()`, the call to super happens before extra buttons are added. These additional buttons are not included in the call to
`_enable_export_buttons_for_common_vat_groups_in_branches()`.

**Fix:**
Instead of calling the function in _custom_options_initializer, add an option key to check and enable export buttons. This check is now done in `get_options()`, using the same logic previously applied in `_enable_export_buttons_for_common_vat_groups_in_branches`. As `get_options()` is called after the custom options initializer, all buttons are enabled if all branches with the same VAT are selected.

task-4061157

Forward-Port-Of: odoo/enterprise#79227