Improve symmetry of store / remove in CoordSystemAdaptor

dbConnection.t: do not use $dbh->ping() to check if disconnected from DB [master]

Added prepare_cached as a wrapper to the DBConnect.pm module

s/localtime/gmtime/ for successful tests down under.

registry.t: Skip the testing of load_registry_from_db() parameter-name auto-correction on databases other than MySQL

A bugfix implemented in DBD::mysql between 4.049 and 4.050 means that
pinging a MySQL server now implicitly reestablishes the connection if
down for whatever reason. Moreover, it is not clear from DBI
documentation whether ping() is supposed to check if the connection to
the database was open before calling it or not (it says "if the database
server is still running and the connection to it is still working",
which may well mean the _network_ connection between the client and the
server rather than an open _database_ connection) and the behaviour of
specific implementations varies. For instance:
 - DBD::Oracle: according to documentation it returns "either 0,
   indicating that the connection is no longer valid, or 1 indicating
   the connection is valid", under the bonnet it calls either OCIPing()
   (if available) or OCIServerVersion(). In light of the facts both of
   these methods take a service-context handle as an argument and that
   disconnect() calls OCIServerDetach(), which quite thoroughly releases
   resources allocated to the database client, it is likely ping() will
   return 0 if disconnected;
 - DBD::Pg: according to documentation it checks "if there is a
   working connection to an active database server", the code under
   the bonnet is non-trivial but the module's test suite indicates
   ping() is supposed to return 0 after disconnect();
 - DBD::SQLite: according to documentation it checks "if the
   database connection is active", under the bonnet seems to rely on
   the "Active" flag (see below);
 - finally, DBD::mysql - documentation simply says "this can be used to
   ping the server" and under the bonnet the module explicitly attempts
   to reconnect to the database, which only did not happen due to the
   aforementioned bug.

In light of the above, we now check the "Active" attribute of the
database handle to check if we are still connected. According to DBI
documentation, "the exact meaning of active is somewhat vague at the
moment. For a database handle it typically means that the handle is
connected to a database ($dbh->disconnect sets Active off)"; the latter
is indeed the case for all four DBD modules mentioned above.

This fixes dbConnection.t test failures when running with
DBD::mysql-4.050.

Note that there are still some occurrences of ping() in the test file,
however in the remaining cases it is called as a method of
$dbc->db_handle rather than of $dbh. These should in theory be one and
the same but just to be extra careful, we will take care of those
separately.

Document a feature: update() removes web_data

2019 copyright update

I call update() to populate analysis descriptions, from a script `ensembl_genomes/eg-pipelines/scripts/production_db/analysis_desc_from_prod.pl`. I found this when I was searching why `analysis_description.web_data` wasn't populated in WormBase ParaSite. Ensembl probably populates `analysis_description.web_data` differently, and has it working.

 As far as I see the code has been like that for a long time (2 years?), and there's some special behaviour and disclaimers about this field which I don't understand. I also don't really understand the consequences of making the column populated again. So I'm calling it a feature instead of a bug.

@nerdstrike you might know what to do with it!

Updated ensembl_ontology schema scripts

revert patch 94_95_c

production schema file has been renamed

ENSCORESW-2967: update schema to 96

Use seq_region_start and seq_region_end when updating gene coordinate…