[IMP] hr_{work_entry,attendance,holidays,holidays_attendance}: sequential time rule pipeline engine

Adds a configurable threshold-based engine that automatically reclassifies
attendance and leave records when a worked-hours threshold is crossed, and
optionally creates or deducts compensatory-leave allocation credits.

MECHANISM

A rule (hr.time.rule) expresses a condition:

  "When employee X works more (or less) than Y hours on day/week D,
   reclassify the excess (or deficit) as work-entry type Z and grant
   (or deduct) N% of those hours as compensatory-leave allocation."

Rules run sequentially in sequence order. Each rule sees the already-
reclassified output of all prior rules, so they compose cleanly:

  Rule 1 - excess > 2 h -> Overtime
  Rule 2 - excess > 4 h -> Double-time   (evaluates the post-rule-1 pipeline)

KEY MODULES

hr_work_entry
  hr.time.rule           rule model, field definitions, pipeline entry point
  _evaluate_rules        builds initial intervals, runs rules in sequence,
                         extracts excess and deficit per (employee, source) pair
  _evaluate_period       period-level threshold: compares worked hours against
                         the employee's schedule or a fixed expected-hours value
  _apply_output          writes results: reclassifies sources in-place or creates
                         child output records; collects allocation credit tuples
  HrTimeRuleSourceMixin  abstract trigger layer inherited by hr.attendance and
                         hr.leave; fires the pipeline on validated create/write
                         and exposes daily/weekly cron entry points for undertime

hr_attendance
  attendance_validation  per-company policy: when an attendance counts as a
                         validated pipeline source (immediate, officer, tolerance)
  _apply_attendance_output  base implementation - no allocation tracking

hr_holidays
  leave_compensation_rate / allocation_type_id  output fields on the rule
  _apply_leave_output    excess -> hr.leave.allocation credit;
                         deficit -> allocation deduction
  hr.time.rule.allocation.log  per-source log of credits; allows precise reversal
                               when a source record is modified or deleted

hr_holidays_attendance
  bridge module: attendance-based excess/deficit also creates/deducts
  hr.leave.allocation records using the same log + reversal mechanism

TRIGGER TIMING:
  On write/create (for daily excess rules)
  Daily cron for yesterday's daily undertime
  Weekly cron for weekly rules
 
Task-6158746

Label printing offered limited formats and inconsistent layouts across products, inventory, and manufacturing. Adding new label designs also required duplicating report classes, actions, and data preparation.

Add QR label variants for Dymo, 2x7, 4x7, and 4x12 PDF formats. Add redesigned normal, alternative, small, and jewelry ZPL formats with optional prices and packaging.

This commit's changes:
- Standardizes names, pricing, packaging, barcodes, and extra content.
- Shares PDF, Dymo, and ZPL rendering and pagination infrastructure.
- Moves model-specific data preparation into the corresponding wizards.
- Applies the new formats to products, lots/SNs, locations, operation types, packages, and finished products.
- Removes obsolete report classes, actions, and templates.

task-6127471

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

Auto-plan used to assign open Field Service interventions to technicians purely based on their availability, with no notion of where the technician or the customer actually is. This could send a technician to two customers an hour's drive apart back-to-back, or send them off without accounting for the trip back to their own home or office. This only affects interventions that have a customer set — shifts without one keep being planned exactly as before. And if a customer's or a technician's location can't be determined, the intervention is left unplanned rather than scheduled without regard for travel.

Auto-plan now takes travel time into account when assigning interventions to technicians. For each open intervention, it looks for the technician and time slot that fit best while respecting:

- The technician's working schedule (only assigns within their actual working hours/days).
- The technician's other confirmed interventions that day (no double-booking, and no cutting it too close before/after them).
- Any material assigned to the technician already booked at that time, so sharing it with another intervention doesn't create a conflict.
- The driving time between two consecutive interventions, or between an intervention and the technician's home/office when it's the first or last of the day.
- The technician's required role/skill for the intervention, as before.
- A technician's maximum workload for the day, for technicians without a fixed schedule.

Among every technician and time slot that satisfies all of the above, the one requiring the least total driving time is chosen. The auto-plan works in any scale if MapBox is not enabled. If, however, MapBox is enabled, the auto-plan only works day-by-day to account for the runtime of estimating travel times (see below). Open shifts which are in 'draft' are considered as plannable anytime of the day, respecting the resources' work schedules. Interventions are planned in priority order: priority and long ones first, since they are the hardest to fit in, then shorter ones to fill the remaining gaps, and finally interventions with no requested date at all, if any availability remains.

Travel times are first estimated using two different approaches, depending whether a MapBox token is set. In the negative case, a simple Haversine (straight-line distance) is used with a fixed average speed. In the positive case, we employ MapBox's isochrones API [1] and interpolate travel times between the different contours.

At the end, and if MapBox is enabled, the true travel times are computed and the interventions just planned are rescheduled (iff they are in draft).

See odoo/upgrade#11332

task-6200253

[1] https://docs.mapbox.com/api/navigation/isochrone/

[IMP] hr: make the Working Schedule required on employees

Employees could previously be left without any resource_calendar_id,
using standalone "Hours per Week"/"Hours per Day" fields on the
employee/contract as an implicit "flexible schedule" signal instead.

Since resource.calendar now supports a "variable" calendar_type that
can hold zero predefined attendance slots::
a flexible employee can simply be assigned a variable-type
calendar with no slots.

This commit:
- Makes hr.version.resource_calendar_id required, and removes the
  "Flexible" placeholder and standalone hours fields from the
  employee form.
- Turns hours_per_week/hours_per_day into read-only fields related
  to the calendar instead of independently editable values.

- Redefines is_flexible/is_fully_flexible: instead of keying off the
  calendar being absent, they now key off the calendar being a
  variable-type calendar with no predefined slots (fully flexible
  additionally requires no hours_per_week/hours_per_day target).

  Task-6296065