**Description of the issue/feature this PR addresses:**

When a batch recompute of `vies_valid` contains both a parent (commercial) partner and a child sharing the same VAT, and the child happens to be iterated before its parent, the child ends up with `vies_valid=False` instead of the parent's real, freshly-checked value.

**Current behavior before PR:**

`_compute_vies_valid` loops over `self` in whatever order the batch happens to have:

```python
for partner in self:
    ...
    if partner.parent_id and partner.parent_id.vies_vat_to_check == partner.vies_vat_to_check:
        partner.vies_valid = partner.parent_id.vies_valid
        continue
    status = partner._check_vies_iap()
    partner._update_vies_status(status)
```

`Field.compute_value()` removes the whole batch from the "to compute" queue *before* running this loop (it does so upfront, in case the method does not assign every record). So when the loop reaches a child and reads `partner.parent_id.vies_valid` to reuse it, that field is no longer marked "to compute" for the parent, and reading it just returns whatever is currently cached/stored — which, if the parent has not been processed yet in this same loop, is still the old/default value. The child copies that stale value and, being a stored field, keeps it forever: nothing re-triggers its computation afterwards.

Example:
```python
parent = env['res.partner'].create({'name': 'Parent Co'})
child = env['res.partner'].create({'name': 'Child Address', 'parent_id': parent.id})
child.vat = 'BE0477472701'   # queues the child's compute first
parent.vat = 'BE0477472701'  # queues the parent's compute second
child.vies_valid   # False, even though the VAT is valid
parent.vies_valid  # True
```

**Desired behavior after PR is merged:**

Every partner without a parent is always computed before any child that may reuse its value, regardless of the batch's original order — so the child correctly ends up with the parent's real `vies_valid`.

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

Forward-Port-Of: odoo/odoo#287251
Forward-Port-Of: odoo/odoo#279927

Which flag stands for a language is a presentation choice, not a property of its code. `_compute_field_flag_image_url` derives the URL from the country part of the locale, and a site that wants a different flag for a language it offers, a regional one or the flag of the country it actually serves rather than the one the code names, has to compute that URL its own way.

That is not possible today. The field passes the compute as the function object:

    flag_image_url = fields.Char(compute=_compute_field_flag_image_url)

`determine()` takes the `callable` branch and calls that object with the recordset. A plain function is not bound, so the implementation of `base` runs whatever class the record has: a module that inherits res.lang and defines `_compute_field_flag_image_url` changes nothing, and nothing says so. No error, no warning, and the field keeps answering the same URL. Getting around it means redeclaring the field only to replace its compute, which is more than the situation calls for.

Passing the method name puts the computation back on the MRO and costs nothing else: `Field.get_depends` resolves a string with `resolve_mro` and collects `_depends` from every implementation it finds, so the `@api.depends('code', 'flag_image')` declared here keeps applying, to this implementation and to an override alike.

This is the same kind of fix as #185419, which made the `domain` of a field reachable by an override for the same reason. Two field declarations in the codebase still pass a function object this way; the other is `website.menu.is_mega_menu`, which passes `inverse` the same way and is left alone here.

### Problem

`sign/static/src/scss/iframe.scss` sets the background of `.o_sign_sign_item.o_color_constant` with

```scss
background-color: hsl(0, 0%, 80%) / 0.9;
```

That slash is not the modern CSS alpha syntax. Sass parses it as a division of a color by a
number: `hsl(0, 0%, 80%)` is `#cccccc`, each channel is divided by 0.9 (204 / 0.9 = 226.67 -> 227)
and the rule compiles to an opaque `#e3e3e3`. Constant sign items lose the transparency they were
meant to have and render a shade lighter than the `o_color_responsible_*` items right above, which
do use 90% alpha.

Generating the `sign.assets_pdf_iframe` bundle also logs, every time:

```
DEPRECATION WARNING: The operation `#cccccc div 0.9` is deprecated and will be an error in
future versions. Consider using Sass's color functions instead.
```

### Fix

Use `rgba()`, the way the two `o_color_responsible_*` blocks just above already do.

Compiled with libsass 3.6.5 (the compiler `ScssStylesheetAsset` uses):

| | compiled output |
| --- | --- |
| before | `background-color: #e3e3e3;` plus the deprecation warning |
| after | `background-color: rgba(204, 204, 204, 0.9);`, no warning |

18.0 is not affected: there the rule was written as a plain `opacity: 0.9`. In saas-19.4 the same
declaration already reads `rgba(mix(...), .9)`, so this only brings 19.0 in line with it.