Description of the issue/feature this PR addresses:

Website and Mass Mailing both define the same fields (social_*) for the same model (res.company) while being independent of each other.

The ORM will generate a new xmlid for any given field in the form of module_name.model_name_field_name, however the "unicity constraint" doesn't care for the module_name part of the xmlid, i.e. if field X of model A is defined twice, only one xmlid is generated.

This means that the xmlid for these social_* fields are generated only for the first module that is installed, and the second module piggybacks off of the first module's fields, this causes issues upon uninstalling the first module, since the second module won't be able to piggyback off of the first module's fields.

Current behavior before PR:

Installing website then mass_mailing in that order, then uninstalling website will raise an error because mass_mailing won't be able to find the social_* fields.

Desired behavior after PR is merged:

Installing website then mass_mailing, then uninstalling website (and viceversa) works without data loss / traceback.

Additionally, people who wish to create modules requiring the social media options in res_company, can add this minimal new module as a dependency.

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Before this commit:
To know if an event menu is an auto generated one (eg: location, register..),
it checks if the menu name is the same as the hardcoded one in
_get_standard_menu_entries_names.
Is user change the menu name, the code won't retrieve it and will act as if the
menu had been deleted and it would recreate it.

This leads to 2 bugs:
*First (website_event)
 - Change menu name from website_event (eg: location, introduction or register)
 - Check/Uncheck 'Track on website' or 'Track Proposals on website' to force
   the code to rewrite missing menus.
 - Go back to the event front end, theses menus have now been recreated, and
   are duplicate.

*Second (website_event_track)
 - Check 'Track on website' on event back end
 - Change the 'Talks' menu name in front end
 - Go back to backend, 'Track on website' is unchecked because
   _compute_website_track won't retrieve an event menu named exactly 'Talks'

Now, we store the original name of the menu and we check based on that field if
the menu is (still) present.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:


--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr