Review end to end the slug saving flow

[Tofandel]

A few things this PR tackle:

1. Performance of saving slugs: we now check if the slug attributes were modified to know if the slug needs to be recomputed, this means no query at all if no slug change. A lot of unnecessary or duplicated queries were also removed. A single slug creation before needed between 10 and 16 queries and now only runs between 3 and 6

2. Get slugParams was split between 2 functions which for the most part duplicated the logic. It is now all encompassed into the original function, deprecating getSingleSlugParams

3. There is a lot of confusion regarding multiple slugAttributes https://github.com/area17/twill/issues/755 as well as in the code, some parts of the code used slugAttributes to generate a concatenated slug, some other parts of the code assume that the first is the slug and the rest is additional columns in the slug table (but the later doesn't make much sense because it would just copy an existing attribute into the slug table, so I do not understand what it achieves). To avoid a breaking change a $slugFields property and $slugDeps property were introduced, if they are not defined, it will fallback to $slugAttributes to determine those

Superseedes #2688 Fixes #2681 #2693

The new $slugFields goes a long way in the path to fully support https://github.com/area17/twill/discussions/860 (right now it will correctly generate it from all the fields in the backend but not yet the browser side)

[ifox]

Thank you so much for diving into this @Tofandel.

We do have a few projects that use multiple slug attributes. This is used in tandem with parent-child modules, so that children of different parents can reuse the same slug without a suffix. So the second attribute we add in that case (and a column in the slugs table) is the parent ID.

[Tofandel]

In that case maybe I can instead add a new property for slugAttributes so that we can get the new behavior without a breaking change