Extend comment syntax in Khiops dictionaries

== Contexte ==

Contexte: gestion des commentaires dans la version actuelle (V10)
- les commentaires sont prefixes par '//'
- on peut mettre des commentaires a peu pres partout
- pour chaque groupe de lignes de commentaire, on ne conserve que la premiere ligne de commentaire, les autres sont ignorees
- on garde les commentaires suivants, attaches aux entites du langage
  - dictionnaire: commentaire precedent le debut de declaration du dictionnaire
  - variable: commentaire de fin de declaration d'une variable
- tous les autres commentaire sont toleres, mais simplement ignores
  - n'etant rattache a aucune entite du langage, ils ne sont pas geres
  - quand on re-ecrit un dictionnaire, ils ont disparus

Besoins d'extension:
- pour une ligne de declaration de variable trop longue, on prefere parfois mettre un commentaire avant la declaration d'une variable
- besoins potentiels de commentaires multi-lignes
- pour un usage classique d'edition d'un fichier kdic, besoin de commenter tout ou partie d'un dictionnaire,
  sans perdre les specifications apres lecture/ecriture d'un fichier dictionnaire
- pour un usage de type APIU via pykhiops core dictionary, besoin de garder chaque comemntaire associe a ue entite du langage

== Specification ==

Specification
- a chaque entite d'un langage, on associe:
  - un libelle court
    - `label` actuel dans pykhiops, pour les entites Dictionary, Variable et VariableBlock
    - dans un fichier kdic, en fin de declaration, sur la meme ligne, pour les variables et les bloc de variables
    - dans la GUI: champ Label dans la liste des caracteristique d'un dictionnaire, obtenus via "Inspect dictionary"
  - un commentaire multi-lignes
    - `comments` a ajouter dans pykhiops, pour les entites ayant deja un label
      - commentaire multi-lignes
    - dans un fichier kdic, liste des commentaire lignes precedent une declaration d'entite
      - les commentaires parses sont trimes (comme les labels)
      - on peut ainsi avoir plusieurs lignes devant une variable, ou devant un dictionnaire
      - mais les lignes blanches restent ignorees
      - quand on re-ecrit un dictionnaire, on ecrit les commentaires lignes
        -  en tout debut de ligne pour les commentaires associes au Dictionary
        - au niveau de la declaration de type pour les commentaire de Variable ou VariableBlock
    - dans la GUI, on ne voit pas les commentaires
- dictionnaire
  - label: le premier commentaires ligne present avant la declaration du dictionnaire, ayant un role de titre avant les comemntaires
  - comments: tous les commentaires lignes (sauf le premier) presents avant la declaration du dictionnaire
    - tolerance du parser, pour accepter des commentaires n'importe ou entre le debut de la declaration et le debut du bloc '{'
      - avant en debut de la declaration
      - avant les elements de declaration facultatifs: cle et meta-donnees
      - avant le debug du bloc '{'
    - au moment de l'ecriture, ils sont tous ecrits avant la declaration du dictionnaire
  - internal comments: les commentaires suivant la derniere variable, avant la fin du bloc '}'
- variable
  - comments: tous les commentaires lignes presents avant la declaration de la variables
  - label: le commentaire de fin de ligne, en fin de declaration de la variable
- block de variable
  - comments: tous les commentaires lignes presents avant le debut du bloc de variable '{'
  - comments: tous les commentaires lignes presents avant la fin du bloc de variable '}'
  - label: le commentaire de fin de ligne, en fin de declaration du bloc de variables
- tout commentaire autorise par le parser sera conserve, en etant rattache au mieux a une entite du langage
- les commentaires sont interdit
  - en fin de fichier, car non rattachable a une entite du langage
  - au milieu d'une declaration de variable, ou d'une regle de derivation
  - au milieu de la partie obligatoire de la declaration de dictionnaire (("Root") "Dictionary" <Name>)

Avantages
- extension significative avec des commentaires multi-lignes
- faible cout de développement et maintenance
- on peut faire une documentation plus pedagogique, compatible avec le parser de kdic
- dictionnaires via API pykhiops:
  - ils sont tous correctement associes a une entite du langge
- dictionnaire via edition de fichier kdic
  - on garde l'exhaustivite des commentaires des fichier kdic, auparavant ignores pour partie
  - on peut commenter plusieurs variables, le temps de la mise au point
    - ces variables commentees ne seront pas perdues
    - effet de bord: leur commentaire sera associe a la variable suivante (pas grave)

== Implementation ==

Impacts principaux dans KWCLex.lex
- ajout d'une regle pour parser les commentaires
- ils sont prefixes par '//' comme les libelle, mais sont seuls sur leur ligne

Impacts principaux dans KWCYac.yac
- token existant coments renomme en label
- ajout d'un token comments de type StringVector*
- regle kwclassFile: on interdit les commentaires en fin de fichier
- regle kwclass: prise en compte des commentaires internes de fin de bloc
- regle kwclassHeader:
  - on accepte les commentaire a presque tous les endoit possible
    - au debut
    - avant les cles
    - avant les meta data
    - avant le debut de bloc '{'
  - le premier commentaire precedent le debut de declaration sert de libelle
  - ils sont tous concatenes pour etre conserve
  - les commentaires apres le debut de bloc '}' servent de InternalComments
- regle kwclassBegin: prise en compte des commentaire internes en fin des blocs d'attributs
- regle label: 0 ou 1 token LABEL
- regle comments: 0 a n tokens COMMENT
- regle labelOrComments: libelle ou commentaires
- regle kwclassBegin, cas d'un bloc d'attribut: prise en compte des comemntaire de debut de bloc
- kwattributeDeclaration: prise en compte des commentaires prededant la declaration de l'attribut

Refactoring
- Pour toutes les regles acceptant potentiellement aucun token (reperees par le commentaire /* NULL */),
  on fait desormais systematiquement passer cette option en premier au lieu de en dernier.
  Cela reduit les risques de conflit de regles, notamment pour les commentaires optionnels,
  ou le parser ne fonctionne pas sinon.

== Tests ==

Nouveaux jeux de test dans dans LearningTest\TestKhiops\Advanced
- CommentedDictionary
- CommentedMTDictionary
- CommentedSparseDictionary

Tests complets sur LearningTest