Steps to reproduce:
- In the website builder, select an image
- Click on "Shape"
=> It takes several seconds to open, without any feedback to the user.

In [commit 1], the `Img` component's `onWillStart` was wrongly rewritten
to await the image load.
In this commit, we don't await the `Img` load to avoid a laggy
interface.

When each `<Img>` in a group appears one at a time, the visual effect is
not optimal. In such a case, we can wait for all the images in the group
to display them all at once.
This commit adds an `ImgGroup` wrapper component to be used in those
situations. After the 1st load, images are cached by the browser and
should appear immediately.

Note that the intent of the `ImgGroup` was initially to also display a
placeholder until the images are shown. This was finally scrapped, as
the builder images should load fast enough that we don't need to
actually show a placeholder. As a matter of fact, if present, those
placeholders give a worse impression because they trigger several visual
changes on the page in a small time frame.

[commit 1]: https://github.com/odoo/odoo/commit/3cc5ff6e96493f2b068090f880987def3787895e#diff-b4107c5542b3089f488c9a60dd38df72710d0702d5c1ee2de36eb80bc884697c

task-4367641

*: event, website_event, website_hr_recruitment

The functional desire is to be able to access the website app as a basic
internal user and see records views that you can see.
In practice, there are quite a few technical issues preventing that (the
user easily gets hit with "you don't have the rights to access this"
because of internal fields of the main models and screens could maybe be
different or the framework should be a bit more smarter about this.

This commit adds bandaids on the problem to at least allow some access
without warning on some things (by hiding specific fields in the website
views, etc). The main reason for this commit is keeping the no-demo
runbot tests happy (especially in later versions where it became the
standard). In master, this should definitely be reviewed to work more
robustly and more well-thought from a functional point of view.

Some (all?) examples of issues solved: as an internal user without any
access rights (except being an internal user), try to:
- Access the kanban view of events in the website app
- Group the list view of events by "stage" in the website app
- Access the list view or kanban view of jobs in the website app
- Go on an event in the website app, try to access the form view with
  the related top-right button
- Go on a job page in the website app, try to access the form view with
  the related top-right button

Note: the publish button also kinda has the same problem for pages. This
will be fixed in a dedicated PR after this one.

runbot-161791

Forward-Port-Of: odoo/odoo#219356
Forward-Port-Of: odoo/odoo#219128

Steps:
- Install  `account_accountant`
- Open bills
- Create two bills with two different PDF
- Go to list view, open first bill
- On the pager you have now 2 records (1/2)
- Click on the attachment_preview to open PDF in a PopOut
- Click on the next button in the pager
- PopOut is not updated (still with the first PDF)

since https://github.com/odoo/odoo/pull/214726

Before to this commit, the popout service returned an object containing `createManager` (which also contains useful getters such as `.id` and `.externalWindow` used to retrieve the window and communicate with it), and it also contains all createManager's methods using the following code:

```js
    return {
        createManager,
        ...createManager(), // ❌ Converts getters to static values
    };
```

But all that getters become obsolete as a copy of the object is made at that precise moment and so, for example, `externalWindow` will remain null forever instead of being re-evaluated each time it's accessed.

Since other parts of the code (such those in charge of updating the popout when props are updated) use `externalWindow`, this no longer worked at all, as it never detected an external window.

The solution (in stable) is to use this code instead:

```js
    const service = createManager();
    service.createManager = createManager;
    return service; // ✅ Preserves getters behavior
````
This ensures `externalWindow` getter is properly re-evaluated on each access and returns the current state of the external window.

In master a fix containing breaking changes will be made to improve the service.

opw-4948511

Forward-Port-Of: odoo/odoo#219296

When dealing with a "return for exchange" case, some SM won't be merged

To reproduce the issue:
1. Confirm a SO with a product
2. Process the delivery
3. Return > Return for exchange
4. Process the receipt
5. Set the SOL qty to 0

Error: a receipt is created. The second delivery should actually be
canceled

This happens because the SM from step 5 is not merged into the SM of
the second delivery. When editing a SOL qty, a procurement is ran
and its values are based on the SOL:
https://github.com/odoo/odoo/blob/66c5d10833af8946ab5d3f887086f9ba08d36ab3/addons/sale_stock/models/sale_order_line.py#L228-L230
https://github.com/odoo/odoo/blob/66c5d10833af8946ab5d3f887086f9ba08d36ab3/addons/sale_stock/models/sale_order_line.py#L378
Where we define a specific `date_deadline`
https://github.com/odoo/odoo/blob/66c5d10833af8946ab5d3f887086f9ba08d36ab3/addons/sale_stock/models/sale_order_line.py#L260

However, when we return for exchange, we also run a procurement, but
its values are defined differently:
https://github.com/odoo/odoo/blob/30e60b55736cfd5f3116ebbc680b49d9113ca419/addons/stock/wizard/stock_picking_return.py#L238
And nothing defines `date_dealine`

Since the values of both SM are not the same, they won't be merged, cf
https://github.com/odoo/odoo/blob/9f8c364f056c8937409f8ed91b8d1fa436c2d7c0/addons/stock/models/stock_move.py#L1119
Hence the creation of the receipt picking

OPW-4688679

Forward-Port-Of: odoo/odoo#218431