[FIX] website: enable to add a description on form field

Steps to reproduce:
- Add a "Form" snippet on the website.
- Select the first field.
- Try to toggle the "description" option of the field.

-> Problem: there is no description added on the field.

The problems appeared since [this PR] and comes more precisely from
[this commit]. The problem is that one condition required to fill the
`default_description` parameter is that `field.type === "description"`.
This should not be the case. Indeed, here was the flow before
[this commit]; When the user toggled the description option,
`toggleDescription` assigned `field.description` to `true`. The field
was then rendered trough `renderField()`. During this rendering, the
system called the `website.form_field_description` template through
`website.form_field` independently of the field type. Because
`field.description` was set to `true`, a `div` with the description
"Describe your field here." was added on the rendered field. To solve
the problem, the `field.type === "description"` condition has been
removed as a condition to set the `default_description` parameter. Now,
as it was the case before [this commit], this parameter is filled either
if `field.description` is set, either if the field name is `email_cc` or
`email_to`.
The error probably comes from the fact that the name of the template
used to render the field is `"website.form_field_" + field.type`. As the
name of the template in charge of rendering the description is
`website.form_field_description`, the author probably thought that this
template should only be called when `field.type === "description"`. This
is not the case; the template `website.form_field_description` is always
called when rendering a field (independently of the field type through
the template `website.form_field`) but is only relevant if
`default_description` is set.

Note that this fix fixes also another bug:
- Add a "Form" snippet on the website.
- Add a field which is of type "Cc".

-> Problem: there should be a description of type "Separate email
addresses with a comma." on the field.

This commit also adapts the `website_form_editor_tour` tour to verify
that the description option works as wanted.

[this PR]: https://github.com/odoo/odoo/pull/130467
[this commit]: https://github.com/odoo/odoo/commit/363251986dcd753796b4b037a2da2e118b3e8e35

opw-3630348
opw-3604548

Currently, when replenishing a product using a supplier that has a discount, the purchase order created didn't take the discount into account. It was set to zero. Fix in `purchase` module, test in `purchase_stock` module.

Steps to reproduce:
-------------------
* Go to ´Inventory´ > ´Products´
* Select any product
* Configure the product:
* - Product type: storable
* - Enable ´can be purchased´
* - Under the ´Purchase´ tab, add a vendor with a discount
* - Save
* Select ´Replenish´
* Select the vendor previously added
* Confirm
* Check the PO created

Why the fix:
------------
After debugging, I discovered that
```python
po_line_values.append(self.env['purchase.order.line']._prepare_purchase_order_line_from_procurement(
    procurement.product_id, procurement.product_qty,
    procurement.product_uom, procurement.company_id,
    procurement.values, po))
```
in `/home/odoo/odoo/addons/purchase_stock/models/stock_rule.py` would loose the discount value.

Discount can be found in `procurement.values.supplier.discount`.

Further investigation revealed that function `_prepare_purchase_order_line(self, product_id, product_qty, product_uom, company_id, supplier, po)` in `/home/odoo/odoo/addons/purchase/models/purchase_order_line.py` would not make use of the discount value.

In this function, we use the discount value from the seller instead of the supplier as the seller is computed in order to use the smallest discounted_price.

opw-3640396