Follow up of tasks 2379518 and 2633229 (#73341 and #77156).

Purpose
=======

The main goal is to allow the portal user to click on some stat button shown in the task form view in the project sharing feature. Those stat button will redirect to a portal view if the portal user has access to the document(s).

Then, some refactoring is made to easily use the existing code for one route to another one and review the code for the project sharing tour.

Finally, the `/my/project` and `/my/task` routes have been renamed to follow the same *naming* in the another routes. That is, those routes will be named `/my/projects` and `/my/tasks`.

## Details of the implementation

- Allow the portal user to click on the sale order stat button in task form view. This stat button will be clickable if the user has access to the sale order of the current task shown in the form view, otherwise the stat button will be invisible. If a portal user clicks on this button, then he will be redirect to `/my/orders/<id of the sale order>`.
- Allow to show the parent task from another project than the one shown in project sharing. If the portal user has access to the other project than there is no reason to not allow him to see the parent task.
- Rename the `/my/project` route into `/my/projects`.
- Rename the `/my/task` route into `/my/tasks`.
- Create hook methods to avoid duplicating code when we want to use this code to another route. It will be the case for a new route used in the project sharing feature.
- Create hook method in controller of account module to easily reuse the existing code for another route for project sharing feature.
- Refactor tour js for project sharing feature to remove the duplicating code.
- Revert the disable click on avatar. This changes was initially done for project sharing feature. However, this changes is made `web` module instead of the `project`. Since this changes is no longer used in project sharing feature and no used in backend code, the changes is reverted.
- Move the `invoice_count` field from `sale_project` module to `industry_fsm_sale` one because it seems this field is only used in that module and not anywhere before installing that module.

task-2648955

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Follow up of tasks 2379518 (community PR odoo/odoo#73341 and enterprise one #19483) and 2633229 (community PR odoo/odoo#77156 and enterprise one #21155).

Purpose
=======

The main goal is to allow the portal user to click on some stat button shown in the task form view in the project sharing feature. Those stat button will redirect to a portal view if the portal user has access to the document(s).

Then, some refactoring is made to easily use the existing code for one route to another one and review the code for the project sharing tour.

Finally, the `/my/project` and `/my/task` routes have been renamed to follow the same *naming* in the another routes. That is, those routes will be named `/my/projects` and `/my/tasks`.

## Details of the implementation

- Allow portal user to click on ticket stat button shown in the task form view. This stat button will be clickable if the user has access to the ticket, otherwise the stat button will be invisible. If the portal user clicks on this stat button, he will be redirected to `/my/ticket/<id of the ticket>` route.
- Rename `/my/task/<task_id>/*` into `/my/tasks/<task_id>/*`
- Allow portal user to click on the quotation stat button shown in the task form view if he has access at least to one quotation. When the portal user clicks on this button, he will be redirected the route displaying the quotes related to the task which he can see.
- Move the `invoice_count` field from `sale_project` module to `industry_fsm_sale` one because it seems this field is only used in that module and not anywhere before installing that module.
- Allow portal user to see invoices of task, that is the portal user can clicks on the invoices stat button to see the invoices related to the task. However, this button will be clickable only if the user has access to at least an invoice is accessible for this user. Also the `invoice_count` in project sharing will count only the invoices the user can see.
- Filter timesheets in project sharing based on the `sale.invoiced_timesheet`. Indeed, when the `sale.invoiced_timesheet` setting is equal to `approved` then the portal can only see the validated timesheets. Before this changes is correctly the case, but the total of effective hours shown into the task form view is not the total one of the timesheets he can see into the view but all the timesheets related to this task.
- Fix the calculation of `quotation_count` field in project.task model to only count the quotations added via the `Create Quotation` button shown in the `project.task` form view instead of counting all the quotations related to the task.

task-2648955

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

When a user selects cells in the grid, it can be used by multiple
components/plugins: selection itself, composer, selection input.
Each one of them should be independent and decoupled. They currently
are not independent and it's a mess because only one of them can be
"focused" at the same time. The focused component is determined implicitly
with a set of flags/modes in different plugins.

E.g. Go on A1. Start the edition and select a cell distant from the
edited cell. Once you validate the edition, the selection on the grid
has been moved to the last selected cell but it should be in A2.

Problem 1
---------

When one component/plugin is focused, it needs to tell others to defocus
by "manually" dispatching precise commands which resets their flags/modes.
It's hard to follow, it's fragile and it's easy to forget to dispatch the
proper command(s) which would lead to an inconsistent state.

Problem 2
---------

Selection commands are currently dispatched to all plugins (multi-casted)
which needs to decide if they should handle it or not based on their own
state and the state of other plugins. Changing the state of one plugin can
affect (and potentially break) others.

Solution
--------

With this commit, we introduce a centralized mechanism to manage the focused
element. This centralized mechanism is called the "selection processor".
Plugins no longer needs to know each other and are now decoupled.
By design, only one component can be focused at the same time.

The selection processor:
- processes all user inputs and computes the new/updated
anchor zone based on the current anchor zone. The new anchor zone is then
dispatched in the form of an event to the focused plugin. All business logic
of computing the next anchor zone is encapsulated there. Plugins only need to
know what is the next anchor and (sometimes) the user intention (add the zone
to the selection, reset the selection, etc.).
*This addresses the second problem since the flow is now split. Updating the*
*selection is a simple method call and the resulting event is sent to the unique*
*focused (uni-cast)*.

- notifies the focused plugin when another captures the focus, no more need to
dispatch specific commands in several places. The plugin is responsible of itself.
*Solves the first problem*.

- is usually called by the UI(components).

- will work with a state provided by the focused plugin which
allows a better granularity and the independency of states of each plugin.
e.g. When edition is focused, there is only one zone (reference) registered at
a time, even if the cell contains several of them.

Task 2698011

Co-authored-by: Lucas Lefèvre <lul@odoo.com>