report de [16475] et [16476] sur l'affichage de la bonne erreur sql quand on traite avec plusieurs serveurs

simplifier les fonctions de date pour sqlite en reposant dans tous les cas sur _sqlite_func_unix_timestamp et date(),
plutot que de recoder une regexp differente, possiblement bugguee, dans chaque fonction.

(plus coquille de nom de variable et indentation)

_sqlite_func_unix_timestamp ne fonctionnait que si heure:minute:seconde etaient bien present dans la date.
On debug la regexp, mais, encore plus simple, on la remplace par strtotime qui fait le job aussi bien.

dans sql_insertq et sql_updateq on utilisait spip_mysql_cite en lui passant le type.

Bien que sql_quote puisse prendre le type en argument, lui utilisait toujours _q() ce qui ne donnait pas un resultat equivalent (cas typique de '0001' stocke dans une chaine que _q transforme en 1).
On change donc cela : lorsque le type est fournit a sql_quote, il utilise spip_mysql_cite qui saura faire ce qu'il faut, sinon il s'en remet a _q comme avant, qui fait de son mieux sans rien savoir du format de stockage.
On traite les tableaux par propagation du type, afin de ne rien casse de la compatibilite de sql_quote

mysql transforme "binary" en "collate utf8_bin", qui coince quand on veut remettre ca dans sqlit. filtrons le aussi.

'timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP'
il faut couper le ON UPDATE que sqlite ne supporte pas ici

Dans create_base, on peut passer un nom de base prefixe par un path, qui est prioritaire sur _DIR_DB
Dans la connexion, on peut preciser un path dans le parametre $addr

Remise en ordre de l'installation : reprendre leprocessus de la branche 2.1 qui installe les extensions

La liste des bases disponibles en PG avait sauté lors de la révision générale des erreurs SQL de [14543].

Correction PG, fixe #1840: pourquoi [10883] a mis dans la version PG de cette fonction un traitement particulier pour WHERE, absent de la version MySQL ? Ce traitement réapplique le jeu de RegExp déjà appliqué, ce qui rajoute des bugs sans en enlever semble-t-il.

Généralisation du 8e argument de la fonction spip_connect_db: on accepte maintenant un tableau de longueur 1: 'nom d'authentification' => 'fichier de connexion',
l'ancien format "chaîne de caractères" étant toujours pris en charge avec son a priori que le nom de l'authentification est "ldap".
Ce 8e argument est mémorisé dans l'index "authentification" de la globale "connexion" décrivant l'installation.
Cette mémorisation du 8e argument est effectuée par spip_connect_db qui ne le transmet plus aux fonctions de portage SQL qui n'auraient en fait jamais dû le recevoir.

boucle(Toto) est pareil que boucle(TOTO), c'est MySQL qui ne les identifie pas avec sa syntaxe {{{ SHOW TABLES LIKE 'TOTO' }}} ; alors que, bien entendu, il interdit de creer une table TOTO si la table toto existe deja...

Amélioration de la portablité des instructions de date SQL. On introduit la foncton {{{sql_date_proche}}}, qui prend en argument un champ de type date (ou équivalente), un nombre entier et une unité de temps en anglais, et qui construit un test SQL répondant vrai si ce champ est compris entre maintenant et l'intervalle de temps indiqué (dans le passé si négatif, dans le futur sinon). Au passage, il apparaît que le remplacement de NOW() par l'équivalent SQL permettrait de faire plus de choses en PHP. Pour l'instant ça reproduit le code SQL antérieur (mais parfois > a été transformé en {{{NOT <}}} ce qui est inexact mais semble sans conséquence). 

Le porte pour MySQL a été reproduit tel quel en PG (en attendant d'y mettre en l'oeuvre l'améioration produite, pour SQLite, je n'ai pas vu où déclarer la fonction.

Ajout dans l'interface SQL de la fonction {{{sql_create_base}}}, afin que le caractère d'échappement propre à MySQL n'apparaissent que dans le portage de celui-ci, pas en dur dans le code de l'installation.

Révision générale des erreurs pour PostGres, cf [14529]. Là aussi il y a des cas particuliers d'erreurs qui risquent de ne pas apparaître des les logs, à terminer.