Closes #242 

Pour resoudre le pb du ticket #283, nettoyage du HTML pour qu'il soit presque valide HTML4, ce qui a permis de trouver un Div non fermée qui pourrait 
expliquer le problème.

Quelques remarques pour atteindre la validation (j'écris en majuscules ce qui devrait etre entre chevrons):

La suite de balises "A TABLE A" n'est pas valide html4, donc la classe 
cellule-h est completement à refaire.

La suite:
SCRIPT document.write('DIV style...') /SCRIPT NOSCRIPT DIV /NOSCRIPT
ne sera jamais valide, il faut trouver d'autres écritures.
En l'occurrence j'ai carrément supprimé la partie Noscript, ça n'a pas l'air
de gener.

permettre aux plugins qui ajoutent des raccourcis typo de les nettoyer proprement lors du calcul d'une introduction

spip_style.css divorce (en douceur) de l'espace privé : les modifications de dist/spip_style.css n'ont désormais plus d'incidence sur l'espace privé

Traiter les docs de la même manière qu'ils soient affichés en corps de texte d'article ou via le portfolio (= utiliser les mêmes styles).

+ suppression du inserer_attribut qui, de toute façon, n'était pas pris en compte, sur #EMBED_DOCUMENT

code non conforme a la doc (http://www.spip.net/fr_article1827.html)

#URL_ARTICLE{5},#URL_RUBRIQUE{5},#URL_BREVE{5},#URL_MOT{5},#URL_FORUM{5},#URL_DOCUMENT{5},#URL_AUTEUR{5}

du coup je les vérifie tous

Mettre absolument des apostrophes autour des flottants sinon Mysql arrondit lorsque c'est affecté à une chaine ===> version_installée 1.911 devient 1.91 et on boucle à la mise à jour ....

Petite réorganisation du script d'importation: l'attribut "version_archive", suffixant "inc_import_" et apres codage de '.' en '_' donne le nom de la fonction responsable de la remise en base du contenu de l'archive. Ca permet d'une part de ne pas charger tout le code pour les 3 versions actuellement connues (d'où les 3 fonctions/fichiers inc_import_1_3 etc), mais ça ouvre surtout la porte à l'exploitation de petites archives destinées à compléter une base existante plutot que de la remplacer entièrement. Par exemple, prendre la table des mots-clé  d'un site et le mettre dans un autre et autre SIEPS (qui n'est plus à jour). Evidemment ca reste à écrire, mais tout le mécanisme de sécurité et de reprise en cas d'interruption sera déjà géré.

- ca evite les chargements automatiques foireux
- ca servira pour les autres portages.
Mais faudra penser à renommer.

ajouter rel="tag" dans les liens de mots-cles -- si on regarde http://www.sifry.com/alerts/archives/000433.html c,est plus que standard desormais, il ne faut pas attendre de tout microformater

Nouvelle implémentation du critere IN qui ne pouvait pas etre conditionnel auparavant (exemple: {id_mot ? IN (66, 62, 64)}) et devrait etre plus rapide car  reposant sur Having+field plutot que in+find_in_set

Formulaires : second correctif rapide, concernant essentiellement les styles pour formulaire_login, login.html et formulaire_login_forum

Les champs de saisie n'étaient plus visibles (suite à 6400) => correction rapide (doit être mieux réfléchie).

Pourquoi ? pour permettre d'avoir une déclinaison très souple d'une page à l'autre. Par exemple, pour le plan du style, qui a toujours bénéficié de styles qui lui sont strictement propres.

C'est vrai que ça donne des idées tellement la surcharge CSS devient facile.

Tache #209: Remplacement des addslashes spécifiques à SQL par la fonction spip_abstract_quote pour faciliter le portage SQLite. Cette fonction retourne son argument intact si c'est un nombre, ou le met entre apostrophes avec \ sur les apostrophes internes sinon. Il faudra toujours l'utiliser pour SQL a present,
et exclusivement pour cela.

La transformation des fichiers a été obtenue par le script suivant:

#!/bin/sh
a=$(grep -l "'\" *\\. *addslashes([^)]*) *\\. *\"'" */*p)
for i in $a
do
sed -e "s/'\"[[:space:]]*\.[[:space:]]*addslashes\(([^)]*)\)[[:space:]]*\.[[:space:]]*\"'/\" . spip_abstract_quote\1 . \"/g;" -e 's/ *\. *""//' $i > x.php
mv  x.php $i
done

plus quelques interventions manuelles, en particulier, le FIND_IN_SET du critere IN a ete remplacé par un FIELD, plus facile a produire dans ce contexte. Il y avait aussi un peu d'incoherence entites_html / addslashes ici ou là. Enfin, le Having, actuellement toujours inutilisé par le compilateur, est a nouveau bon pour le service.

Tâche #209 pour le addslashes, mais il y avait une variable de langue qui n'était pas déclaré globale pour les mots, et impossibilité de redonner un titre à un groupe de mots clés qui l'aurait perdu