[FIX] calendar: prevent computed fields to be manually defined

Suppose Google Calendar synced with Odoo. When the user updates a
recurrent event on Google, syncing with Odoo may cancel the change.

To reproduce the error:
(Need google_calendar)
1. [On Google Calendar] Create a recurrent event
2. Sync with Google Calendar
3. [On Google Calendar] Move one of the recurrent events
    - Its date must be different
4. Sync with Google Calendar

Error: The updated event didn't move. On Google Calendar, the event has
moved to its initial date.

At some point, when updating a recurrent event that has moved, the
method `detach_recurring_event` is called. This method is in charge of
getting all data before creating the moved event. However, to get all
data, it first calls the `read` method and then adds some other
information:
https://github.com/odoo/odoo/blob/acaca80f0ce544d1c9a738a5aac992a8ac9c75b2/addons/calendar/models/calendar.py#L1409-L1420


And here is the problem. The method `read` provides additional
information, such as `start_datetime` and `stop_datetime`. However,
theses fields are computed based on the *calendar_id* of the event. Such
an identifier is like `<ID>-<Date>` where *Date* is the initial date of
the event. Therefore, `start`, `stop`, `start_datetime`, ... will be
incorrect.
Back to `detach_recurring_event`, `data` will be updated with some other
values and with `values`. Hopefully, since the latter contains the new
start and stop dates, `start` and `stop` will be overwrote with correct
values (i.e., dates of the moved event). However, `start_datetime` and
`stop_datetime` are still present and incorrect.
Therefore, because of the presence of these two variables, the method
`_inverse_dates` is triggered on creation of the new event. This one
recomputes `start` and `stop` based on `start_datetime` and
`stop_datetime`, but theses fields are incorrect (they are equal to
intial start and stop dates). This is the reason why (1) the updated
event didn't move and thus (2) on Google Calendar, the event has moved
back to its initial date.
This fix suggests to remove several fields from `read` method, because
some undesirable behaviors may happen. Moreover, since these fields are
computable, it's easy to get their (correct) value.

OPW-2474721

closes odoo/odoo#69150

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>