This is very convenient when we use portal_templates.upgradeSite to
make sure some bt will always be installed with force=1. This is
usually used when we have a bt patching other bt.

Allows implementing user-based restrictions on classical ERP5-style
rendering.

This functional change should have been in a separate commit.

Commit accidentally reverted "IE use the latest rendering engine to
render the page". Reapply the change.

That template is only to be used for ERP5-style UI.

That template is only to be used for ERP5-style UI.

To encourage creation of alternative templates for web mode,
as this template must not be used outside of ERP5-style UI
(aka "ERP5 XHTML Style").

Sadly, we still implement our own escaping, as places escaping strings do
not know which connector will be used (proper escaping is
connector-dependent, because database-dependent).
Move this method in ZSQLCatalog to factorise code.

Disabled by default (configurable by user preference).

Also, reorganise erp5_auto_logout code:
- logout: Do not duplicate original code.
- twiddleAuthCookie: Simplify & factorise.
- setAuthCookie: Resync features with Cookie Crumbler's, and set http_only flag.
- ERP5Site_getMaxUserInactivityDuration: Cached access takes the same time as actual access (and access is surprisingly slow, actually), so do not cache.
- Base_getAutoLogoutSessionKey: New script, to factorise session key generation.

Editor Field does not escapes value, String Field does.

also :
* remove Accept-Encoding from Vary header, because Zope's response does not differ by Accept-Encoding request header.
* use getModificationDate() for modification time if available.

Editing a text containing </textarea> was breaking the field

this commit fixes the following commit :
* patch : Caching Policy Manager should not override existing response headers.

erp5_web_renderjs_ui: create link when a sub field is not editable but it's in listbox's editable column

We have to use destination since this what we define on production orders (not source).
Make sure we display correct values if a resource is used by several lines.

invoicing: invoice transaction builders should find corresponding deliveries only through explanations

What happened before :
- user confirm sale invoice
- activity for building vat invoice lines is created
- user change destination_section
- since builder was expecting having same destination_section on delivery
and simulation movements, it was failing

Now, the builder does not look at source/destination or other categories, it only looks
for common explanation. This can be done this way only because transaction lines should
go inside the same delivery as invoice lines with standard invoicing.