This commit removes a loophole in the evalContext used in form,
list and kanban views to evaluate python expressions (modifiers,
domains and contexts). Before this commit, the evalContext was a
mix of different things:
 - keys of the current context (which also contained keys from the
   user context);
 - a key for each field in the view (allowing to use field values);
 - a "parent" key in the case of x2many records (allowing to go up
   to the parent record values).
 - "active_id", "active_ids", "active_model", "current_company_id".

All those keys were mixed in the evalContext, and they could
obviously conflict (e.g. if there was in the context a key which
was also the name of a field).

Even though the evalContext didn't contain an explicit "context"
key, expressions like `context.get("x")` worked. This was because
the python evaluator automatically adds the whole evalContext as
value for the "context" key if this one doesn't exist. This allowed
people to also access field values with `context.get("fieldName")`
and thus bypassing the view validation, which ensures that
everything used in those expressions is either a py builtin
supported by pyjs, a field name which is in the view or some other
whitelisted keys ("uid", "allowed_company_ids"...). Fun fact:
people did it, in a form view that is used on two different models
(product.product and product.template).

With this commit, the context (and user context) keys are no longer
spread into the evalContext. Instead, a "context" key is added.
Two special user context keys can still be accessed directly though,
without doing `context.get("...")`: "uid" and "allowed_company_ids".
The reason why we keep them is simple: those were the two only keys
that could be used directly as they were whitelisted by the view
validation. The client also evaluates domains and contexts coming
from actions and from search view filters. In those cases, the
evalContext is simply the context, and those two keys are widely
used. So it's easier if we know that, e.g. "uid" can be always
directly accessed, whether we're in an action domain, in a search
view or in a form/list/kanban view.

To summarize, accessing a context key must always be done through
`context.get("...")` except for "uid" and "allowed_company_ids",
which can still be accessed directly. This doesn't change from
before. What changes is that a record field can no longer be
accessed with `context.get("...")` (which kind of allowed to bypass
the view validation).

Impacted modules:
- helpdesk
- website_helpdesk
- website_helpdesk_knowledge

This commit introduces various improvements in the Help Center on the website.

Banner Edition
==============
Purpose: allow users to customize the help webpage, as it is possible for other web pages

Currently the banner of the help center is not editable by the user as it contains a search field. The search fields is moved out of the cover to allow the the user to personalize it.

Publish Button
==============
Purpose: move the published button to the systray to be coherent with what is usually done in website + we don't need it anymore now that we have 1 help web page per helpdesk team.

- help webpage: move the published button to the systray
- ticket submission webpage: move the published button to the systray

Knowledge Article
=================
Purpose: allow users to easily edit the article set on the team from there.

- helpdesk.team form view > knowledge feature > display the external link icon next to the article field

task-3186564