Even if the model is called res partner category, it is now used like tags
and should be labelled as such.

You probably want to know what you won over the month.

This option implies 3 changes:
 * a default char field x_name on the new model
 * be able to infer the `model` of the ir.model in name_create
   from its `name`
 * avoid deleting the registry when unlinking *nothing* ; the default
   field_id or ir.model ([(0, 0, ...)]) implies an unlink ([(5,), (0, 0)])
   that delete the current registry

Courtesy of @rco-odoo

As these views will soon be accessible out of debug mode,
let's simplify them by hiding some fields in non-debug mode.

As this lib will be used in the backend, it is moved to assets common.

The API of `Registry` has been modified as follows:
 - `Registry(name)` returns the registry of the given database
 - `Registry.new(name)` forces the creation of a new `Registry` object
 - `Registry.delete(name)` discards the given registry
 - `Registry.delete_all()` discards all registries
 - `registry.setup_signaling()` initializes the signaling for `registry`
 - `registry.check_signaling()` returns an up-to-date `registry`
 - `registry.signal_registry_change()` notifies that `registry` has changed
 - `registry.signal_caches_change()` notifies potential cache invalidation

This merge holds several long awaited improvements for the mail gateway.
It includes

 * store email status of notifications emails sent to customers
 * display this information on Chatter
 * improve bounce email management: track bounced notifications emails, use
   message_bounce fields directly in mail and not in mass_mailing
 * send emails to assigned user on records
 * remove required alias on users while keeping it possible to define alias
   on users and use them
 * handle emails forwarded to aliases as new threads instead of replies
 * do not store needaction for forum and blog posts
 * automatically unsubscribe partners that bounce on channels
 * some light code cleaning

If a partner bounces more than 10 times on a channel, unsubscribe him from the
channel.

Forum and blog are public models that could have a lot of followers. After
notifying followers of a new comment, discard the needaction information.
For those models email is considered as sufficient. This way we avoid storing
a lot of unnecessary entries in the m2m table between message and partner.

It has been solved using the standard way of managing buttons in notification
emails. At least we hope it.

Having followers having an email address being an alias is rarely a good idea.

If the 'To' of an incoming email is an alias on another model we now consider
this emails as a forward to a new alias. A use case for this is an email on
a task that should be considered as an issue and forwarded to another alias.

When a user is assigned to a model on a user_id field an email is sent to him
containing a link to the document. This way the user is warned he is now
responsible of the task / issue / lead / ...

Using after commit event notifications emails are now send once the current
transaction is finished. This allows having issues with emails being sent
while the transaction failed sometimes after email sending, but still in the
same transaction.

A small hook is done to allow invitation emails to be sent directly as some
data related to mail.message is unlinked directly in the wizard.

This commit remove required alias on res.users model. It also removes the
inheritance of mail.alias.mixin. The field alias_id is kept and allow people
to use aliases on users if they want. However there is no default void alias
created for each user anymore.

Default from of mail.message does not use user alias anymore. Indeed this
creates issues with aliases not being correctly configured and can be
confusing compared to private channels. Using user aliases is therefore
now done manually instead of being a default behavior.

Handle bounces using bounce alias directly in mailgateway. Previously bounces
were used only in mass mailing to update campaign statistics. Now the
mailgateway tries to find data from standard delivery status emails. This
data is used to update state of emails sent to customers, to display it in
the Chatter. It is also used to increment the message_bounce counter on the
bounced partner and bounced record, if any and if the field exists.

Previous more generic code that detect bounces is kept. This code is more specific
to standard delivery failure notifications by parsing its content.

Currently it is impossible in Discuss to know whether an email has been sent
to a customer and whether it failed or bounced. A notified partner has an
entry in the needaction m2m table. In this commit we decorate this table to
add fields about the email notification: is an email sent, did it failed, did
it bounce.

This information is kept only for customers. Internal users does not use this
information. Moreover their notification is deleted once the message is read
in the Chatter. This avoids having a notification table that grows quickly.

Chatter now holds a new icon for email details. It allows to know on a thread
status of emails sent to customers.

This is an old compatibility code. It is time to remove it as it is not used
sinces ages.

Previously Return-Path were composed using bounce_alias-<mail_id>-<model>-
<thread_id> . However this may lead to return adresses not supported by
the incoming mail server. We now form the bounce alias using bounce_alis+
<mail_id>-<model>-<thread_id>. Using a + indicates that the right part of
the address is for information and used to manage the bounce. Only the
left part is used for the email routing, allowing the return email to
effectively land in the alias mailbox.

When a new answer comes in a thread the mailgateway finds if the recipients
are linked to existing aliases. This allows notably to check if the author
can effectively contact this alias. Previously only the To was checked.
However we cannot ensure the recipient is contained in To as it could be
in Delivered-To for example. We now check for all possible recipients.

The purpose of this commit is to clean a bit the code related to email
routing in the mailgateway: message_route and message_route_verify.

message_route is now clearly separeted into two categories. First one
handles emails considered as answers to existing threads. Second one
handles emails that have to create new threads, either through alias or
default behavior of the mailgateway.

message_route_verify has been a bit facotrized to simplify the various
overrides that appeared lately in the codebase.

This commit only contains code cleaning. No functional change should occur
due to this commit.

Before creating a account analytic line related to a sale order, check that the sale order is in 'sale' state, i.e. not a quotation, not in done or canceled state.

The issue is that when validating an expense (for example, but it's the same for a timesheet), the analytic account line is created even if related to a canceled sale order which is obviously wrong. This was leading to confusions about what's displayed, what is existing and not displayed and whatever.

This was the behavior before this commit 48ea59d4

mail.mail and mail.thread have methods to decode headers. This commit
move them in mail tools. It is indeed simplier to have all email tools
in the same file. Moreover they have been renamed to avoid confusion
with standard library methods: decode and decode_header already exist.

 * decode in mail_message is now decode_smtp_header
 * decode_header in mail_thread is now decode_message_header

A method to data from references is also moved into tools. A regex was
already defined in tools. Now the method using it is already put in tools.
Mailgateway will now simply call this method.

Previous version of the test was actually not correct. Mailgateway was not
considering references as in-reply-to when trying to find answers that have
to be considered as a new thread instead of an answer to an existing thread.

Purpose of the test is actually to be sure that answers considered as a new
thread have no parent_id set. Otherwise you may have threads linked to
messages belonging to other records, leading to access right issues. Moreover
if this email begins a new discussion thread it makes no sense to have a
parent message set.

A new test is written to better simulate the test case. It sets a message_id
containing reply_to which is the way odoo uses to indicated that answers
to a message have to be considered as new threads. This is used notably in
mass mailing for example.

We already know that a user is a shared user. This means a partner created
for a customer for the purpose of sharing data. However sometimes it is
interesting to know that a given partner is a customer or a partner linked
to a shared user. This will be used notably in the Discuss app.

This drops the backward compatibility with the old API:
 - remove method wrappers;
 - convert all the remaining old-API calls to the new API;
 - remove the processing of _columns, _defaults, _inherit_fields, _all_columns;
 - remove all old-API fields;
 - implement sparse fields;
 - modify the registry to become a mapping model_name -> model_class;
 - adapt XML-RPC and JSON-RPC gateways.

For the sake of simplicity, the method adapter `call_kw_multi` does not look up
for `ids` in keyword arguments, instead it expects it in positional arguments.

Also refactor the test to prevent private methods to be remotely called.

Methods can no longer be called in both APIs.