In this commit, we perform the below changes:
 - add a 'tags' m2m field below the SOL one
 - add a 'tags' configuration menu with an editable, optional, and
   multi-edit list view and  set a random color automatically on
   newly created tags
 - In the list view:
     move the SOL field to the right of the task_id one
     move the company_id field to the left of the 'start date' one
     add the tags field to the right of the SOL one
 - kanban view: display the tags field below the task_id one
 - search view: add a quick search on tags
 - search view > filters: rename the 'unpublished' filter into 'draft'
 - add a 'my department' filter that should return the shifts assigned
   to employees who are in the same department as the current user
 - display the 'i take it' button in secondary if the role set on the shift
   is not one of the roles of the current user
 - search view > filters
    - remove the separator between 'to schedule' and 'employees on time off'
    - move the 'employees on time off' filter below the 'shifts in conflict' one
    - move the shifts in conflict/employees on time off / to schedule filters
      below the 'my team' one (with a separator in between them)

task-2700231

## Purpose

### Customer Rating in Helpdesk

Before this changes, the Helpdesk use the customer satisfaction to show the rating average for a Helpdesk Team. This compute was made only in Helpdesk, since in the related community PR, we also use the rating average this compute is made in the `rating.mixin` to avoid duplicate the field and its compute. As in the tasks in the project app, the last rating value is used to determine the final satisfaction of the customer for a ticket. But the final result could be done the last work doing in this ticket and not the result for the global work done in this ticket.

To do this, the idea of this change is to use the rating average to globally see the customer satisfaction of a ticket or even a Helpdesk Team based on the customer satisfaction of each ticket related.

### Add `group_use_rating` group

A new group is added for helpdesk app, it is called `group_use_rating`. The idea of this group is the same then the one for SLA feature called `group_use_sla`. The idea is to add the group of the helpdesk user when at least a helpdesk team has the 'Customer Ratings' enabled. When no helpdesk team has the feature enabled then we remove the group.
With this group, we are now able to show/hide filter only used for this feature is enabled/disabled.

For planning, when `sale_planning` module is installed, the user can set a SOL to a shift (`planning.slot` model). Moreover, if this user has no access to Sales app, then he can even open the form view of the SOL when he is in the form view of a shift with a SOL. This behavior is not expected and remove this permission to grant it only if the current user has access to the Sales app (at least the `sales_team.group_sale_salesman` group).

task-2671848

Community PR: odoo/odoo#81027

RATIONALE

"Appointment" should be usable on its own, using only internal users and the
appointment schedule if the management of employees is not necessary. This can
give the basic appointment flow to users without commiting them to use the work
hours of employees, giving flexibility and reducing the db size if hr is not
needed. The use of work hours is made flexible (not mandatory) and the appoin-
tment schedule can now be sufficient, even if hr is installed and no employee
is set for the staff member.

BEFORE THIS COMMIT

The appointment module had 'hr' in its dependencies. The employees linked to an
appointment type were of type hr_employee, limited to employees linked to an
internal user. The employee work hours were always considered when computing
its availabilites and available slots for the appointment. Slots of appointment
types were always limited to both the work hours and calendar events of emplo-
yees.

PURPOSE OF THIS COMMIT

This commit removes a non-necessary layer between the appointment and its staff,
by making the table of hr_employees (with domain to only have ones linked to an
internal user) a res_users one. It allows at the same time to remove the hr
dependancy since the related features are mostly separatable from the rest and
put all that logic in a new module appointment_hr.The only time it has to be
changed is in the computation of available slots, removing the automatic use of
employees work hours.

Most of this commit is code moves and rewording. However, disseminated changes
had to be done to make it clean and working. Here are the main points:

--- NEW APPOINTMENT_HR MODULE:

- Hr is removed from the dependencies of appointment. It means that 'resource'
  module is also not available anymore.
- Features moved in new module:
    - The whole 'WORK HOURS' appointment link flow, since it only depends on hr:
        - The button is added in the dropdown on calendar view (JS), but is hid-
          den if the current user has no employee.
        - The category selection field of appointment types has the 'work_hours'
          choice added.
        - Related tests (and useful data) are adapted and moved to new module,
          both in python and js.
- Availabilities computation is updated (see below)
- For now, it is an auto-install bridge module depending on hr and appointment.

--- REWORDING:

- In the code, 'employee_ids' is replaced with 'staff_user_ids', and other vari-
  ables are updated the same way: 'employee' <- 'staff_user'
- In the docstrings and readable expressions, 'employees' is changed to 'staff
  members'
    -> In second commit, this is set back to a simplier 'Users' or 'Staff Users'
        when confusion with logged user is possible.

--- AVAILABLE SLOTS COMPUTATION:

- In appointment : simplify the computation to include only the calendar events
  of the staff members. The method receives slots already depending on schedule. 
- In appointment_hr : previous behaviour is restored, but employees are not
  mandatory anymore. If an employee is set on a staff member, its work hours are
  considered, but otherwise, only the calendar events are, reconciling both
  behaviours.
- Note : if a user has a resource(_calendar), it has work hours! But this is NOT
  consider in the method, only the resource_calendars linked to employees are.

--- JS: 

- A few functions are added to extract existing bits of logic, to make them
  easier to inherit in submodule.
- Tests:
    - In Qunit module appointment.appointment_link, employee-related data is
      removed in appointment and added back in appointment_hr.appointment_link.
    - The mock server route .../get_staff_user_appointment_types is 'overriden'
      in submodule, but data does not include employee-related. Therefore, it
      does a check to allow Qunit tests of appointment module to still be work-
      ing if the submodule is installed. This is necessary but should be cleaned. 

FUTURE IMPROVEMENTS

It would be very easy to implement a parameter on each appointment type to say
whether slots should be limited to employees work hours or not, creating more
flexibility.


---- Links ----
Task Id - 2499566
ENT PR - odoo/enterprise#17934
UPG PR - odoo/upgrade#2578

When the cron to send the followup report ("Account Report Followup; Execute followup") is triggered,
the email with the followup report sent might not reflect the followup level set in the database.
For example, if you rely only on automatic followup without checking the follow-up report in the interface,
the system will send emails only with the message of the 1st followup level.

The option 'keep_summary' is set by default when we call the send_email() function. This will keep the
last summary set in the report manager. This is ok if we use the interface to send mail because the summary
is updated to the one of the current followup level when loading the followup report page. In the case of
the schedule action (which uses the same function to send mail), this is not because it might sent an
outdated mail (with different amounts/invoices/dates).

This commit removes the default 'keep_summary' = True and set this parameter when we click on the button
"Send by mail" in the follower. So if the cron is triggered it will recompute the summary (mail message)
based on the followup level.

opw-2667996

Forward-Port-Of: odoo/enterprise#23104