Avoid using unnecessay key variables in multi-table feature construction

Contexte
- schema en etoile, construction de variable
- comme la cle d'une sous-table (du moins la sous-partie commune à la cle de la table mere) ne peut contenir d'information
  dejà traitee dans le dictionnaire parent, cette cle n'est pas exploitee pour la construction de variable
- exemple: SpliceJunction
 - la variable SampleId est utilise en cle de SpliceJunction
 - la variable SampleId est utilisee en cle de la table secondaire SpliceJunctionDNA
 - on n'exploite donc pas cette variable

Probleme potrentiel:
- si le champ cle de la table secondaire a un autre nom, cette variable secondaire peut alors
  etre traitee à tort comme un champ non cle distinct de la cle du dictionnaire parent, et etre exploitee pour la construction de variable
- exemple:
  - SpliceJunction, en renommant Sample_Id en SampleId dans la table secondaire
  - les resultats de modelisation en generant 100 variables seraient alors differents à tort

En fait, le probleme est deja traite correctement dans le code
- KDMultiTableFeatureConstruction::ComputeAllClassesCompliantRules
  - on a uniquement enrichi le commentaire, et corrige les typos

Ajout d'un jeu de test dedie LearningTest\TestKhiops\MultiTables\SchemaDifferentKeyNames

src/Learning/KDDomainKnowledge/KDMultiTableFeatureConstruction.cpp

@@ -1589,13 +1589,18 @@ void KDMultiTableFeatureConstruction::ComputeAllClassesCompliantRules(
 			 outputClassDomainCompliantRules->GetAllClassesCompliantRules()->GetAt(nClass));
 		kwcClass = classCompliantRules->GetClass();
 
-		// On interdit les cles de la classe
-		// De facon generale, il s'agit d'un principe: la cle ne sert qu'a encoder une structure et la
-		// memoriser: il ne s'agit pas d'attributs porteurs d'information. Pour la classe racine, les cle
-		// apparaissent une seule fois instance, et ne peuvent etre informatives. Pour les classes secondaires
-		// inclues, les cles sont soient unique par instance principale (la cle de l'incluant) sans interet,
-		// soit avec un role d'identifiant dans la table secondaire, sans interet autre que compter le nombre
-		// d'enregistrements (par CountDistinct, ici redondant avec Count).
+		// On interdit l'utilisation des cles du schema-multi-table pour la construction de variables.
+		// Les cles ne sont des attributs porteurs d'information.
+		// Pour la classe racine, les cles apparaissent une seule fois par instance, et ne peuvent pas etre informatives.
+		// Pour les classes secondaires inclues, les cles sont soit uniques par instance principale (la cle de l'incluant)
+		// et donc sans interet, soit avec un role d'identifiant dans la table secondaire, sans interet autre que de compter
+		// le nombre d'enregistrements (par CountDistinct, ici redondant avec Count).
+		//
+		// De facon generale, les cles ne sont qu'un moyen technique permettant d'encoder une structure, via des
+		// cles de jointure pour lire des donnees stockees dans plusieurs fichiers.
+		// Dans le cas de tables construites par des regles de derivation, les cles ne sont pas utiles
+		// et peuvent meme etre absentes des dictionnaires.
+		// L'information exploitable est ainsi independante du mode de stockage (avec ou sans cle).
 		for (nKey = 0; nKey < kwcClass->GetKeyAttributeNumber(); nKey++)
 		{
 			classCompliantRules->GetForbiddenAttributes()->SetAt(kwcClass->GetKeyAttributeNameAt(nKey),