Commit [1] improved the url dependencies search behavior to include more models to search in but also the multi record capability (needed for multi delete in list view now that website is in the backend).

But a line of code was badly designed, making the perfs horrible. That line code shouldn't have been part of the loop as it doesn't depend of the loop.

This was drastically more impactful on the `/` page.

Benchmark: for the `/` page, searching in 1000 product template website
           description will go from 29.74 seconds to 0.29 seconds.
           See the speedscope result on the PR description.
           **For ~10.000 products, it will go from ~7 minutes to 1.35s.**

[1]: https://github.com/odoo/odoo/commit/6ac17b93437868cbefbe13448a6fcbb29953f221

task-3169378

------------------------------------

Speedscopes:
| Products | Before fix | After fix |
| ------------- | -------------- | ------------ |
| 1000 | 20.46s ![image](https://user-images.githubusercontent.com/30048408/216673975-a7d5d78b-1c94-41d0-b281-422df6d4f357.png) | 0.29s ![image](https://user-images.githubusercontent.com/30048408/216673841-1622f9fb-b2db-4550-b6c0-013111a08484.png) |
| 10000 | ~7 min ![image](https://user-images.githubusercontent.com/30048408/216673668-effdd646-3088-4b50-bdcb-ed953853ad2b.png) | 1.35 secs ![image](https://user-images.githubusercontent.com/30048408/216673593-706851d5-4487-4623-b395-4abe55e44621.png) |

Forward-Port-Of: odoo/odoo#111919

The issue occurs when a computed field depends on a many2many field with a corresponding inverse field on its comodel.  Consider two models like
```py
class User(models.Model):
    _name = _description = 'test_new_api.user'

    group_ids = fields.Many2many('test_new_api.group')
    group_count = fields.Integer(compute='_compute_group_count', store=True)

    @api.depends('group_ids')
    def _compute_group_count(self):
        for user in self:
            user.group_count = len(user.group_ids)

class Group(models.Model):
    _name = _description = 'test_new_api.group'

    user_ids = fields.Many2many('test_new_api.user')
```
When a user is added to a group with
```py
    group.write({'user_ids': [Command.link(user.id)]})
```
we expect the field `group_count` to be recomputed on `user` only, but it is actually triggered on *all* the records in `group.user_ids`.  This is a real performance issue when there are many records in the relation.

The explanation comes from the fact that
 - the framework considers the field `user_ids` is modified on `group`;
 - the field `group_count` implicitly depends on `group_ids.user_ids`, which makes it triggered on the users `u` such that `u.group_ids` intersects `group`.

The solution consists in handling the dependencies on inverse many2many field in the field itself.  The field no longer adds the implicit dependency on its inverse field in the trigger tree, but instead determines which records in the comodel are actually impacted by the relation change in the method `field.write()`.

Forward-Port-Of: odoo/odoo#111653

This patch optimizes the way field trigger trees are computed.  Overall, the resulting trigger trees are mostly identical, but they can now be determined one by one, which enables an on-demand approach and partial cache.

Before this patch, getting the first trigger tree proceeded as follows:
 - resolve the dependencies of all fields;
 - compute the transitive closure of the dependencies of all fields;
 - store the transitive closure above as field triggers for all fields in a cache.

After this patch, getting the first trigger tree proceeded as follows:
 - resolve the dependencies of all fields;
 - cache them as direct triggers for all fields;
 - compute one trigger tree as the transitive closure of the field's triggers, and cache it.

This optimization is quite effective during the installation of modules, and is even more effective when the number of fields is large.  For instance, a complete installation with all community modules is now takes 25% less time.  For a complete installation with all enterprise modules, the installation time is even 30% less!  A medium installation is about 16% less time.

The optimization also speeds up the first request on a new Odoo worker, since the minimum time for computing a handful of trigger trees is much smaller than before.  We have measured times for a first request going from 1.6 seconds to 1 second for posting a message.

We have observed slight differences in trigger trees, but they occur in places where the tree has redundant branches, in particular with fields having recursive dependencies.  It therefore makes no difference in what is being triggered or invalidated.

Forward-Port-Of: odoo/odoo#111941
Forward-Port-Of: odoo/odoo#111651