Remove attribute only if the result is False or None

* The compiled templates are cached per user, lang, inherit context values
* ir.ui.fields: attributes method return an dict, and record_to_html return only the content value of the field
* all rendered text use build_text and all attributes use build_attribute
* t-esc-options is removed and replace by format_value method
* AssetsBundle receive the list files and remains

Template arch can contrains "groups" attributes on the html tag but can't have group_id setted. (to allow a cache per template and lang instead of a cache per template, user and lang)

Allow access if the user has at least one group, and has no one !group
E.g.: groups="a,!b,c,d,!e"
(a, c, b) prevent access
(c) allow access
So the negative groups have precedence.

Search terms inside an OR branch in a domain
cannot currently use relationships that are
not required. The root cause is the INNER JOIN
used to implement it.

This allows the user to continue using the attachment feature, without making it public by
default, which was the case in the previous implementation. If you wanted to use the
product digital attachments, you were foresaking the standard attachment feature since
everything you would attach to the product would then be public and downloadable.

The "digital" product type was also removed, because you could very well want to provide
downloads for a stockable product, like an online manual or a warranty document, or
provide downloads for a service, especially considering digital products are considered
service in european laws.

The product template and variants stat buttons have also been changed:
- The template stat button now only displays the files associated at the template level,
instead of showing all the files available accross all variants.
- The variant stat button now displays the files associated with it but also with the
corresponding template, instead of showing only the files associated with the variant.

These new stat buttons are closer to what the customer will see in practice, since the
variant level stat button will show the set of files that the customer will be able to
download when he has bought that product variant. Previously, the template showed a set
of files that was never presented to any customer (since it contained the files from all
the variants at once), and the variant was showing less files, since it was ignoring the
ones from the template.

The unit price of the quote template lines is never be used anywhere

It is logical that pricelists determine the price of products and this
field is quite informative.

Purpose:
The settings planner (implementation guide) is confusing when in multi-company:
- The accounting planner shows information about the current company; which is OK
- But the planner is not specific to that company: it is the same for all companies which is wrong.

New Enterprise module

Frontend:
- When product has lot/serial tracking open popup for accept lot/serial
  number when it selected.
- Add icon in order line to show related lot/serial number and it
  indicate status of product lot
- User can add or remove product by lot from current lot dialog box
- Order line quantity don't match with lot line quantity show warning
  message

Back End:
- Added model `pos.pack.operation.lot` to manage product lot related
  with pos order
- Added state button in pos session form view to show pickings which are
  not in 'Done' stage

Action action_sale_config has been moved to sales_team addon at
odoo/odoo@fa6e415.

Closes #12319

In master , some places the string "Lot" is used and at some places
"Serial Numbers" is used , which is very confusing for the user.

Make a common string "Lots / Serial Numbers" everywhere for the uniformity.

Purpose:
There are too many apps when someone starts to use odoo.
The user installs an app and see at least 6 menus -> too much !

Specification:
In mail module move contacts menu into new module 'contacts' to avoid this
useless app for new users but that can be useful afterward

Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.

- Move the empty res_config class and the related view from
  base_setup to sales_team (base_setup only contains the 'General Settings'
  model and views
- Move the 'sale' related content from product to sale module (Access rights,
  menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
  crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
  purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)

[FIX] account: move some ir.model.access to sale module
[FIX] payment: Move some ir.rule to website_sale
[FIX] stock: move some ir.model.access rule to sale_stock
[FIX] project: Move some ir.model.access rules to crm_project_issue
[FIX] mrp: Move some ir.model.access rules to sale_mrp
[FIX] calendar: move some ir.model.access rules to crm

Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.

[ADD] sales_team: See own documents => See only his sales team
Moved the "User: Own Leads Only", "User: All Leads" and "Manager" groups from sale and crm
into sales_team module. Add the record rules so that user can see only his Own Sales Team
if "See Own Leads" is sales right and can see all sales teams if he is having sales rights
of "See All Leads" or manager.

When doing an internal trasnfer, you can choose any destination
location in the header, but not on the line

This is problematic when doing a pick-pack-ship transfer. For the pick
move, you may want to change the source destination location (maybe another
warehouse why not) but as the transfer is already validated you cannot
modify it on the form. But with the Operation Details (Pencil button) you
can modify the source/destination location. The only problem is that a domain
is forcing the user to choose a source destination that is a child of the source
destination on the transfer, which makes impossible to choose a destination on
another warehouse. This tool is pretty much advanced, so we don't need to be so
restrictive.

The expected revenue in opportunity.report is in fact the probable
turnover. It was confusing with the field expected revenue in crm.lead.

opw:678062

The color of the button "create_move" in a depreciation line is
green if the related move is posted, orange if it exists but not posted and
red in the other case.

opw:678905

Specifically, replace `not node.getparent()` by `node.getparent() is None`.

portal_sale adds the security rules for website_portal_sale to work proprerly

Closes #12283

When tracking value is converted to be rendered as a message_post, we convert
the date/datetime with the current local from momentjs.

Related to #12327

Courtesy of @aab-odoo for help and review.

In odoo at many places the filter items are having repeated strings eventhough the
fiter works differently , so find all the places where this happens and give
proper string to each filter..

Purpose:
When we create a return transfer, the return location should be selected as
the default destination location of the "Picking type for return". Odoo should
be using that return location as the default return location during reverse transfer,
but only if the default destination location of the "Picking type for return" is a
return location

Specification:
For all transfers, if the default destination location of the "Picking type for return"
is a return location, then the return location should be selected as the default
destination location during reverse transfer.