This PR optimizes the `l10n_ae` module by eliminating repetitive code and improving performance during module initialization.

The UAE state mapping used by `_get_ae_res_company` and `_get_ae_account_fiscal_position` was previously defined separately inside each method. As a result, the same dictionary was recreated on every function call, introducing unnecessary code duplication and runtime overhead.

This PR extracts the mapping into a reusable module-level `_AE_STATE_MAPPING` constant. The template methods now reference this shared mapping and dynamically construct the corresponding XML IDs, avoiding repeated dictionary allocation and simplifying the implementation.

### Cause

In `_get_ae_res_company` and `_get_ae_account_fiscal_position`, the UAE state mapping dictionary was recreated every time the methods were executed. Since these methods can be called repeatedly during chart of accounts template evaluation, this resulted in unnecessary allocations and duplicated code.

### Fix

* Extract the UAE state mapping into a module-level `_AE_STATE_MAPPING` constant.
* Reuse the shared mapping across template methods.
* Dynamically construct the required XML IDs from the mapping.
* Remove duplicated dictionary definitions from individual methods.
* Reduce unnecessary object allocation during template evaluation.

### Benchmark

The state mapping evaluation was benchmarked over 1,000,000 iterations:

| Version | Execution Time |
| ------- | -------------: |
| Before  |        0.0841s |
| After   |        0.0272s |

This results in approximately **68% faster execution** for the benchmarked operation.

This pr is a prototype proposing to not always fetch all fields if we have a lot of records. 

The idea is that reading all (prefetch) fields **for a few record** makes sense because it will  be less expensive to make a slightly bigger request than needed that having to make multiple request to the database (due to the ping) 

In some cases, with **very large recordset**, prefetching all fields can be an issue 
- memory consumption
- putting data in cache takes some time

In this case, we can improve performances by prefething only the needed fields, but this is fragile, can vary per module installed, .... 

The idea behind this pull request is that it _could_ be less expensive to prefetch the field one by one, but for all records 

In a minimal database we have 7000 ir.model.data, lets take 5000 of them

```python
env.invalidate_all()
start = env.cr.sql_log_count
for rec in env['ir.model.data'].search([], limit=5000):
    rec.model
    rec.name
env.cr.sql_log_count - start
```

Before this change, we would have 6 queries and all fields in cache,
-> 1 for the search
-> 5 to prefetch data, 1 per 1000 id

After this change we would have 7 queries and only the model and name field in cache. 
-> 1 for the search
-> 2 to prefetch model and name on the first 1000 records
-> 4 to prefetch data of the 4000 remaining records

Note that this strategy could become slower if we need to prefetch a lot of fields, especially if some of those fields are needed in a place where the prefetch set is broken. If we have 1000 fields and read 10 records, we would go from 2 queries to 11 queries. The only additional query of the previous example is there to show the best possible case for a large recordset needing only a few fields. 

If we decide to introduce that, it could be an opt-in behaviour (using the context) on some specific reports generation that tends to have memory error.