Restructuration complète du critère `{par xxx}` pour y voir plus clair et...

Restructuration complète du critère `{par xxx}` pour y voir plus clair et apporter une petite amélioration

- les expressions telles que `{par num titre}` ou `{par multi titre}` sont extensibles. `{par expr champ}` cherchera une fonction 
  `calculer_critere_par_expression_{expr}` pour gérer cette expression

- une fonction `calculer_critere_par_champ()` est utilisée pour retrouver la table de tri d'un champ demandé.
  Cette fonction est d'ailleurs aussi utilisée par les fonctions `num` ou `multi`. 
  Cela harmonise un peu les diverses utilisations entre ces 3 cas principaux `{par x}{par num x}{par multi x}`.
  
x peut être : 
- un champ de la table (titre), 
- un champ dont la table de jointure est nommé (documents.titre),
- un champ dont l'alias de table est nommé (L1.titre) (à éviter, surtout là pour compat)
- un champ d'exception de jointure (titre_mot)
- un champ d'une autre table dont la jointure est explicite (ARTICLES documents){par taille}
- un champ d'une autre table dont la jointure est possible (DOCUMENTS){par rang_lien}

Le changement est que si la jointure existe déjà pour un champ, le champ sera correctement préfixé de l'alias de table correspondant,
et dans certains cas une nouvelle jointure ne sera pas créé inutilement.

Entre autres :
- `(DOCUMENTS){id_article?}{id_rubrique?}{vu=non}{par rang_lien}`, le ORDER BY de rang_lien est bien préfixé de l'alias d'une table de jointure. 
Il ne peut plus y avoir d'ambiguité sur le champ, rapporté par Mysql si la table de jointure est présente 2 fois. Cependant le ticket #3894 reste entier.