This commit fixes a performance issue with the "All tasks" list view. The issue especially arose when the view was grouped by stages (because groups are opened by default in that case) and when it contained a lot of stages, each of them containing a lot of records. In the worst case, the view could have to render up to 800 records (80 per group, 10 groups opened), and it could take around 20seconds. With this commit, the rendering part is done in around 400ms.

This commit actually fixes 2 issues.

First, in sale_project, there was an override of `isCellReadonly` to force the `sale_line_id` to be readonly if several records with different partners (`partner_id` field) were selected. This override accessed `this.props.list.selection` once per cell (all cells, not only for the `sale_line_id` column), and this is actually a getter which browses through all records, to generate the list of selected ones. This was thus quadratic. This commit applies a similar logic as in [1] to compute the selection only once for the whole table.

Second, [1] wasn't as optimal as expected. Indeed, we tried to compute a flag only once for the whole template rendering, by setting a variable on `this`. However, the ListRenderer template using `t-call` to render each row, a new rendering context is created for each row. By doing
```xml
    t-att-class="getCellClass(column, record)"
```
the `this` inside `getCellClass` is that rendering context object, so it can't be used to share a flag from a row to another. Explicitely calling `getCellClass` on `this` ensures that the `this` inside the function is the instance, which is the same for all rows.

[1] https://github.com/odoo/odoo/pull/153858

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