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