[IMP] website_event_online: ensure to link visitor at registration

RATIONALE

Events are sometimes held online, gathering a community. In this merge we
improve Event application to better support full-online events with improved
tracks, wishlists, chat rooms, ...

PURPOSE

Ensure to have a visitor when people registers, in order to enable wishlist
or notifications. Improve visitor model to keep information when people change
device.

SPECIFICATIONS: REGISTRATION FLOW

This commit ensures a visitor is created when a registration is done on an
event. Creation is done only if a visitor does not already exists like all
visitor-based flows.

In case of multiple registrations made by the same visitor, only the first
registration is linked to the created/existing visitor. We take the opportunity
to update the visitor's information based on the registration's infos.

We also add some fields to get all visitors from an event, based on visitor
and registration link. This could be used for example to contact them, like
sending a mailing or push notification to all attendees of an event.

SPECIFICATIONS: VISITOR LOGIN / INFORMATION UPDATE

When a user is linked to a visitor (e.g. when customer logs in) its partner
is propagated to the registration. Using visitor as middle-model it allows
to propagate information through those models, leading to better contact
data notably.

SPECIFICATIONS: VISITOR IMPROVEMENTS + PUSH TOKEN

In this commit we improve visitor behavior. Currently when there are several
visitors that may be linked to the same user, only the last one is kept and
other one are unlinked.

However visitor model holds push tokens, allowing to store approval for push
notifications. Unlinking records is therefore a bad idea as we may loose
information. In order to solve this an intermediate solution is implemented.
A new parent_id field is added on visitors. Instead of unlinking "duplicates"
we link them to the parent and de-activate them. This means more visitors
are present in database, but this is required to keep push tokens.

A better solution would probably be to separate visitor from push tokens
but as this merge targets a stable version it was difficult to do in a clean
way.

LINKS

Community PR #53540
Enterprise PR odoo/enterprise#11384

Task ID-2252655 (Main Online Event task)
Task ID-2283796 (Event B2Basics / Registration Flow
Task ID-2284043 (Visitor-based track wishlist)
Task ID-2283869 (Notify attendees by push)

Co-Authored-By: Aurélien Warnon <awa@odoo.com>
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>