This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.

Moreover, this feature was misused. It was:
 - left on fields during multiple versions.
 - used on reports (SQL views). This would be ok if the feature was
   complete, but, as is, it was useless.
 - kept unchanged after a second renaming of the field (which can happen
   versions later the first rename).
 - used, even when the meaning of the field changed. i.e. the field
   `archived` has been renamed to the classic `active`, but the value
   in the database should be switched.

Purpose: small cleaning of code linked to mail.mail model in order to
avoid unnecessary overrides

  * create mail: default_fetchmail_server_id in context should be sufficient
    as it is the base mechanism of default_get;
  * write: unused in codebase. Anyway we should not write on mail and if it
    is the case giving fetchmail_server_id directly should be the correct
    way of doing it;

In case of a clean_context use we might loose default_fetchmail_server_id
key. It is used notably for tracking message generation. In that case
this information could be lost. However the whole concept of propagating
a fetrchmail_server-id from incoming mail server to outgoing emails (as
mail.mail is used only for sending email) is strange and does not require
so much specific code.

Sub-part of task 1853147 (pre-cleaning before implementing mail gateway
improvements)
Linked to PR #32974

- splitted the models/mail_mail.py from models/fetchmail.py.
- splitted the views/mail_mail_views.xml from views/fetchmail_views.xml