[FIX] web: issues with bounding rects and mouse hit locations

On my system in chrome 92 there are issues of chrome's hitboxes (and
rounding) being off leading to tests failures, something which given
the adjustment in `triggerMouseEvent` had been an issue in the past.

The first test failure was / is in the "correctly display year view"
calendar test, where the very first event dialog would fail to open
when clicking on the `2016-11-16`.

After tracing through fullcalendar, it turned out fullcalendar was
told to hit `2016-11-*09*`, suspiciously 7 days before the cell we
were looking for in a monthly calendar, hinting to an incorrect
vertical offset / hitbox.

Fix by offsetting the top coordinate in `triggerMouseEvent`, but
rather than just increment by one update the entire thing by trigger
the event right in the middle of the element being targeted, that
seems more reliable long-term, though it could be slightly confusing
for events like mouseenter/mouseover/...

The second issue was with a list test, where two cells are supposed to
be sized equally. Apparently the offset sizes are supposed to be the
rounded version of the actual size (which can be fractional), but
dumping the information of `foo` and `text` I'd get real widths (via
getBoundingClientRect) of respectively 480.46875 and 480.5, and
offsetWidths of 481 and 480 (the smaller of the two in "real size"
is rounded higher than the other one).

In Python we might use `assertAlmostEqual` for this, but we've
apparently not introduced this in JS take the real width and round up
by hand, this fixes the issue as both end up at 481.

Aside 1:

Before finding out the actual root cause I landed in
`_onYearDateClick` with missing data in the events so looked at the
API to figure what I was looking at, and turns out fullcalendar's
event object has documented properties to get the date-converted start
and end bounds of the event, so use that directly instead of doing the
same thing by hand.

Aside 2:

The attributes passed to `triggerEvent` in `triggerMouseEvent` are
pretty much nonsensical, we're getting the element's location using
`getBoundingClientRect` which is based off of the viewport, but
setting the keys

* `screen(X|Y)`, which should be the location of the hit relative to
  *the physical screen*
* `page(X|Y)`, which should be the location of the hit relative to the
  page / document (so takes in account the content scrolled off-screen)
* `layer(X|Y)`, which is the position of the hit relative to the
  nearest positioned (non-static) element, falling back to page if
  there isn't one

The one attribute which matches the semantics / reference of
`getBoundingClientRect` we didn't even set, instead it would be
automatically copied from `pageX`/`pageY` by the events mapping.

Fix that by just providing `clientX`/`clientY` and updating the
mapping functions to not overwrite it.

If the others are needed they should be computed properly based on the
document's bounding client rect and scroll information, as well as the
window's screenX/screenY (and offsetParent for layerX/layerY though
that seems unlikely to be necessary).

closes odoo/odoo#75900

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>