The new "image_url" widget logic provides the ability to provide static image
links in Char fields instead of duplicating the image file in database (+ filestore)
through an Image field (& ir_attachment).

This commits implements the frontend qweb logic for this widget, following the logic
of the existing "image" qweb widget.

PURPOSE

Before this commit, when you used the 'image' widget when the record name was
``..`` (double dots) it couldn't retrieve the image since the double dots was
decoded as the parent directory shortcut. After this commit, the double dots
will be replaced by -- with the downside to loose the true record name.

SPECIFICATIONS

Replace the .. (double dots) with -- in the filename.

Using .. may seem like a strange use case but if you actually try to find
a partner called ".." in a production database, you might be surprised ...

LINKS

Task ID-2241513 (eLearning onboarding and testing)
PR #55567

X-original-commit: dcb7a924c36cd3f3aeef891ddd8830bd66322025

Take the following QWeb snippet:

```
<div t-field="product.image" itemprop="image" t-options="{'widget': 'image'}"/>
```

When the image is rendered, the `itemprop="image"` remains on the
`<div>` tag, it is not set on the `<img>` tag.

We add the support of the `itemprop` option, so it can be added to the
`<img>` tag:

```
<div t-field="product.image" t-options="{'widget': 'image', 'itemprop': 'image'}"/>
```

opw-2076934

SHA-1 is a cryptographic hash function that have weaknesses known since
2005, it has been deprecated by the NIST [1] about 10 years ago in 2011
and Google [2] have been able to perform a collision attack in 2017.

We use SHA-1 in order to generate unique URL for resources that can be
cached by the browser: assets bundle, translations, qweb templates and
qweb images.

Although practical attacks still requires quite a lot of computational
resources, it is time to upgrade SHA-1 to SHA-2.

We have selected the SHA-512/256 variant of the SHA-2 algorithm as
replacement for SHA-1 for the following reasons:

* On 64 bits platform, SHA-512 is the fastest SHA-2 variant, it is only
  ~1.5x slower than SHA-1. [3]
* Keeping only the 256 foremost bits protects against both collision
  attacks and length extension attacks.
* The hexadecimal digest is only 24 chars longer than SHA-1 which is
  nice to have somewhat short URLs.

We have not used SHA-3 because:

* At the moment of writing, it is too slow (~3x slower than SHA-1) [3]
* It is not guaranteed to be available with the Python 3.5 `hashlib`
  module.
* One of the author of SHA-3 is Belgian.

[1] https://csrc.nist.gov/projects/hash-functions/nist-policy-on-hash-functions
[2] https://shattered.io/
[3] http://bench.cr.yp.to/results-hash.html
[4] http://www.commitstrip.com/en/2017/02/27/the-sha-1-alternative/

closes odoo/odoo#36491

Signed-off-by: Christophe Simonis <chs@odoo.com>

Follow up of https://github.com/odoo/odoo/commit/2f932e3a46c6005870e4130b3c3f7151cd521f2d#r34760948

`url_quote` does not escape `/` which leads to incorrect routes when the name
contains `/`.

Also escape `\` to avoid potential issues on different OS.

closes odoo/odoo#36146

Signed-off-by: Christophe Simonis <chs@odoo.com>

* = website_partner, website_profile, website_sale, website_slides

Before
======

Since commit: 2e3848b394748bf23eff0db0d6d92b9e8c9bf875

The images that are resized have additional borders if the target ratio is
different than the image ratio. Those borders are transparent if the image
format supports it, and are white otherwise.

With that current solution, if the background where the image is displayed is
another color than white, it is looking really bad.

Moreover, most images are stored resized like this, so it is not even possible
to decide if it should have borders or not depending on the context, the
original image and ratio is forever lost.

It is also inconsistent because if the image is already smaller than the target
size then it doesn't include borders. In that case it keeps the original ratio
instead of the target ratio. So it isn't even guaranteed that the target
ratio is going to be respected.

After
=====

This commit will solve all of those problems by always keeping the ratio of the
original image.

This implies the views should be taking care of adding borders when necessary.

task-1958000
PR: #31811

It's better to always have a relevant name in the image URL for SEO.

Also make sure there is always an alt on the image.

closes odoo/odoo#31705

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

With this option we can define which field is going to be displayed by the qweb
image widget, while logic is still applied to the original field.

For example, we want to show a thumbnail image but when user updates it with the
web editor, we want to update the actual field instead of the thumbnail field.

This is similar to the preview_image of the JS image widget.

task-34045
PR: #30656