Reverse natural ways, has suggested by the document (presentation) with
reference developer-Calendar

This is useful to get both start and stop dates of movements without the need of
getting directly objects.

All the logic was inside Person_getAvailableTimeMovementList.
Algorithm was old and hard to understand. Move this algorithm to
simulation tool, and rewrite it using the interval library for
having less code to maintain and easier understanding

This makes less code to customize in GroupCalendarAssignment

Calendar Assignments are now handled in a separate module, update
code in consequence

Not only returns start and stop dates, but also quantity defined
on presence periods. This make it possible to set 3 hours availability
in a time range of 10 hours.

When a Group Calendar or a Group Presence Period is updated, it's necessary
to update related Group Assignment stock catalog data since values are dependent.

This allows to define specific security setting and workflow for Group Calendar Assignments. Before
they were inside Group Calendars. Now a Group Calendar Assignment use the specialise Base
Category to specify the corresponding Group Calendar.

Improve sql query to consider only accountable lines and get the avaibility with many nodes in the same query

Move changes on asMovementList method from PresencePeriod to GroupCalendarAssignment to keep Leave Period working as Expected.

This reverts commit cbf5d46e3c1d3e76c6a5376e08617851ce03773c.

remove the calendar base category on Assignment portal type because the relation between Assignment and Group Calendar is obsolete

Add Group Calendar Assignment portal type. It will be used to set the relation with the source and the period

otherwise pylint-1.2.0 seems not working.

ERP5VCS: fix error with recent versions of Git when there's no upstream configured for current branch

constraint_type should be a string instead of a list.

fixup! fix unicodeconflictresolver that was causing the same error when logging the problematic text

fillRecursivePathList could load massive amounts of objects (ex:
all signatures below portal_synchronizations) even if no object was to
be removed. Instead, just iterate given lists (objects handled by
current instance, and actions to perform) and do as much rocessng before
actually attempt to load any object.

Sadly, the data structures available to this code induce an ugly O(n*m)
code, which may be optimised to O(m + log(n)) with more complex code if
really needed (but then, data structure should be improved, with a much
broader effect).