See merge request nexedi/slapos.core!471

  since accountants use directly the system, it is normal to allow include Invoice Lines.

See merge request nexedi/slapos.core!466

See merge request !465

   Ignore the render_oss since it always change after the installation due the update of translation data.

    Use another website for handle OSS (administrative) operations rather them overwrite properties on renderjs_runner itself

See merge request nexedi/slapos.core!468

When using slapos console on scripts defining functions, for example

```py
def my_request(*args, **kw):
  ...
  return request(*args, **kw)
```

the global names such as `request` where no longer available in the
namespace of the function, because of a wrong usage of exec regarding
locals/globals.
Co-authored-by: Kirill Smelkov <kirr@nexedi.com>

See merge request nexedi/slapos.core!459

See merge request nexedi/slapos.core!463

See merge request nexedi/slapos.core!464

   This is a workaround for fixup when objects has internal invalid properties, since we do not want to extend the general error display before replace the json form.

   Unify tests for prevent excessive copy/paste duplication.

  Unify and drop duplicated code present on slapos_payzen and slapos_wechat.
  Update and move tests related to the change

slapos_accounting: Create Payment Transaction before redirect to handle external payment redirection

  Drop builder and alarm for update Confirmed Payment transaction
  Update Payment state gadget (JIO)
  Generate the link from the Sale Invoice Transaction rather them Payment (since they might not exist)
  crm: Update from Unpaid Payments to Unpaid Invoices
  Now we rely on lettered/non lettered invoices rather than payments.

   The usage of Entity_createPaymentTransaction is slightly faster since it is used to create the payment before the redirect.

   Since we arent creating Payments globally, call the builder to
produce a single payment would be overkill.

   isLettered is more accurated to accounting terms and easy to understand.

   The Payment Transaction should be created once the user attempt to pay, and not on every Payment Transaction.

    The implementation shouldn't rely on the existence of Payment Transaction for knowing if the Sale Invoice Transaction is payed or not.

See merge request nexedi/slapos.core!460

See merge request nexedi/slapos.core!461

See merge request nexedi/slapos.core!458