In list views, we have a custom logic for column widths which aims at optimizing as much as possible the available space, and freezing the table such that it doesn't flicker upon user interaction (like editing, adding records, browsing through pages...).

This logic defines, for some field types, the exact width that values need to be properly displayed, especially for dates and datetimes for which we know upfront the format, i.e. the length of values.

However, before this commit, the logic was incorrect. It didn't take into the account the fact that date and time formats are language dependant. It assumed that the required space for the english formats (+ a bit of security margin) was enough. Moreover, the fonts may obviously has an impact as well (some fonts requiring more space to display the same text, than others).

As a consequence, on macos and, for instance, in deutch, date and datetime values were trimmed, which is something we never want: dates and datetimes should always be fully displayed. This is even worse in some languages, like arabic, basque or chinese, in which the month and/or the day of week is displayed in letters.

This commit comes with a more elaborated solution to deal with those variable date and time formats + fonts. We no longer hardcode the ideal widths of dates and datetimes, but instead compute it (lazily) once, by rendering values in the DOM.

This commit also improves the datetime and daterange cases with option "show_time" set to false: in that case, we know those fields only require the width of date values, not datetime, so we can shrink their columns.

Task~4801116

**Steps to reproduce:**
- Install Planning app
- Set the type of view to Gantt
- (Create a shift if there is none)
- Click on `Publish` button
- The period end date doesn't take the last day into account (time is 00:00)

**Issue:**
Gantt model default `_buildMetaData` computation behavior was changed multiple times during previous refactoring:

Previously used:
```
export function computeRange(scale, date) {
    let start = date;
    let end = date;

    if (scale === "week") {
        // startOf("week") does not depend on locale and will always give the
        // "Monday" of the week... (ISO standard)
        const { weekStart } = localization;
        const weekday = start.weekday < weekStart ? weekStart - 7 : weekStart;
        start = start.set({ weekday }).startOf("day");
        end = start.plus({ weeks: 1, days: -1 }).endOf("day");
    } else {
        start = start.startOf(scale);
        end = end.endOf(scale);
    }

    return { start, end };
}
```
Which became:
```
export function getRangeFromDate(rangeId, date) {
    const startDate = localStartOf(date, rangeId);
    const stopDate = startDate.plus({ [rangeId]: 1 }).minus({ day: 1 });
    return { focusDate: date, startDate, stopDate, rangeId };
}
```

**Fix:**
Added `localStartOf` function in the context setup of PlanningGanttModel.

To avoid overwriting current changes for other modules (which could be intended), this was done instead of :
```
export function getRangeFromDate(rangeId, date) {
    const startDate = localStartOf(date, rangeId);
    const stopDate = localEndOf(startDate, rangeId);
    return { focusDate: date, startDate, stopDate, rangeId };
}
```

related commits:
https://github.com/odoo/enterprise/commit/d18639785e622d97102227103d62ddb3a2716be6 https://github.com/odoo/enterprise/commit/c175a848369057cc69596737dcd9d21dd24c9d5c

opw-4580458