Before this commit, receiving a very long message in a channel scrolled at the bottom could move the message list to the end of that message instead of to its beginning. Every message received afterwards then kept the list at the end. The test "should scroll to bottom on receiving new message if the list is initially scrolled to bottom (asc order)" fails on runbot with:

    10. [toBeGreaterThan] expected value to be strictly greater
    > Minimum: 20762
    > Received: 5190.500

This happens because `applyScroll` also runs outside of a patch, on a resize of the message list or on a loaded image, i.e. while a received message is in the store and not rendered yet. Such a run finds no element for the message, scrolls to the bottom of the list, and records the message as the newest one the scroll was applied on. The patch that renders the message then finds no newer message, and keeps the list at the bottom.

This commit fixes the issue by keeping the newest message `applyScroll` recorded when the first newer message has no element yet, so that the patch that renders the message applies the scroll.

Note that the added test delays the registration of the message element, as a resize cannot be timed between the store update and the patch.

https://runbot.odoo.com/odoo/error/946929

Forward-Port-Of: odoo/odoo#286759

**Steps to reproduce:**
- Install `im_livechat` module
- Copy the code from the livechat channel's widget tab
- Paste it in an external website `<head>` (e.g., local python webserver on `0.0.0.0`)
- Start a conversation and send a file from odoo
- Try to download it from the external website
- POST request is sent for the download
- Download fails: `CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.`
- Also when the file is a PDF the preview won't open: `404 (File not found)`

**Issue:**
Mix of multiple issues:
- The download is triggered using a POST request instead of a GET request
(see similar issue for the file viewer [1])
- The file route does not provide the required CORS headers, so requests
originating from the external website are blocked by the browser
- PDF files are rooted to the related path of the `pdfjs` fileviewer
(e.g. `http://0.0.0.0:8000/web/static/lib/pdfjs/web/viewer.html?file=...`)

```xml
<!--
    Template rendering all the scripts required to execute the Livechat from an external page (which not contain Odoo)
-->
<template id="external_loader" name="Livechat : external_script field of livechat channel">
    <!-- the loader -->
    <script defer="defer" t-attf-src="{{url}}/im_livechat/loader/{{channel_id}}" type="text/javascript"/>
    <!-- js of all the required lib (internal and external) -->
    <script defer="defer" t-attf-src="{{url}}/im_livechat/assets_embed.js" type="text/javascript" />
</template>
```

**Fix:**
Make the `downloadFile` helper handle cross-origin URLs by falling back to a native `<a download>` click (like before) when the target route has the same origin as the embedded script. Could use `session.origin` or `new URL(document.currentScript.src).origin` for this. This is done to avoid allowing CORS on the file content route.

The file viewer issue is handled separately by [1].

For the PDF issue we could manually add the origin to the full url everywhere (but we get some `SecurityError` error from the library due to the cross-origin iframe), add the libjs library in the `assets_embed` (not sure it's possible in `im_livechat.assets_embed_external`), or block external PDF preview for now.

[1] https://github.com/odoo/odoo/pull/281330

opw-6444167

Forward-Port-Of: odoo/odoo#287645
Forward-Port-Of: odoo/odoo#286180