- batched _compute_company_ids on returns
- batched return to unlink in _generate_or_refresh_all_returns
- removed redondant call to _generate_or_refresh_all_returns in
  action_save_onboarding_fiscal_year since we want to call it only
  when a value is changed and that's already handled in the write on
  the company.
- batched _is_available_for on reports
- make only one write on the company (and one call to
  _generate_or_refresh_all_returns) when writing or create the fiscal
  year wizard.
- dont delete return created manually with a date before the date of
  the account_opening_date and not yet posted.

Detected from runbot error:
https://runbot.odoo.com/odoo/runbot.build.error/231463

A small workaround is needed on the company when writing the changes
from the fiscal year wizard. This is because related fields are writen
one by one, which then trigger multiple times
_generate_or_refresh_all_returns. To prevent this, we are batching
all the write on the company from the fiscal year wizard in one write.
The opening_date need to be handled separatly since it's not a related
field but still need to be writen on the company, if removed from the
vals during the create it's then not possible to save the wizard anymore.

Also fixed a bug where the returns manually created before the
account_opening_date would be deleted if they were not posted before
the next call to _try_create_returns_for_fiscal_year.

**Detailed Explanation**

We can see the tour being broken when trying to save on the wizard:

<img width="1366" height="768" alt="image" src="https://github.com/user-attachments/assets/9443251c-aee1-4fbe-be2f-27c11bcbb77d" />

So we can do a flamegraph to take a look at what's happening on that database during that time and we can see 2 majors time uses, a call to `_generate_or_refresh_all_returns` triggered by a write on the wizard and a call to `action_save_onboarding_fiscal_year`

<img width="1396" height="855" alt="image" src="https://github.com/user-attachments/assets/a9d310da-2787-4806-951d-e50b8c1da2a8" />

The first call to `_generate_or_refresh_all_returns` took about 7.8s, the second one took about 1.1s

First, we can see a lot of `_compute_company_ids` calls, this is because we have `precompute=True` on this field due to it being needed in the different access rules.

Since all the returns that are created have similar main company, tax unit and return type, we can easily batch them to only call `_get_company_ids` once for all the returns that will be created. Resulting in the following flamegraph:

<img width="1422" height="866" alt="image" src="https://github.com/user-attachments/assets/c52c88c7-0263-44fb-a16c-52456673dc92" />

The first call to `_generate_or_refresh_all_returns` took about 0.8s, the second one took about 1.2s

Another little change we can do is to remove the call to `_generate_or_refresh_all_returns` during  `action_save_onboarding_fiscal_year` and adding the forced_date from the first one to the second one. 

<img width="1294" height="844" alt="image" src="https://github.com/user-attachments/assets/7ad55d06-ecd4-4957-b514-71fffa6de00c" />

We now end up with one call to `_generate_or_refresh_all_returns` that takes 1.4s

BUT, we can still do better. We can see that all we did previously was only do to one thing less.
The "real" problem was the many search calls done in `_is_available_for` during the `_init_options_variants`.

<img width="1268" height="693" alt="image" src="https://github.com/user-attachments/assets/ebae398d-dfdd-4c1e-99ac-44f25e5875e7" />

After the final change, we are down to 0.9s !

One thing to keep in mind, all those flamegraph were done on a dump of a database from a nightly test, which had many companies created as well as **every** modules installed, which means every return types, reports, ... This means those performance improvements wont be as useful on small databases.