leaving the Orphanet parsing options in in case they are needed again later in history

Seems that the ConfigRegistry code was not picking up on the right ontology
database object type. Added what I think is the right one and lets see
if it stops the website from warning so much.

SliceAdaptor has been changed to bring back the karyotype rank and
the karyotype boolean when retriving karyoptype slices. The Slice object
now caches the rank locally. AssemblyAdaptor now adds the list of
karyotype regions for the rest API.

Committing since we are now beyond the branch point in the API. This
allows a FullIdCache to key on various alternative identifiers/keys
generated by the implementing class. It means that if you want this
functionality you need to sub-class FullIdCache.

now supports schema_version and schema_type retrieval

not used directly in the ontology database but allows for compatibility with the core MetaContainer and release version tracking

is not required for ontology database but allows for compatibility with metacontainer and schema version control like other databases

allows for future schema patching
added single table.sql file, replaces the need for individual sql files for each table

successfully tested on farm3 settings

updated log messages to be clearer about which bit of assembly is being updated

compared to the default feature one, does not have 'ID' field, as display_id is not unique for repeats
instead, used for description field

added fetch_stable_id_event and get_event methods for archivestableid, in adaptor and object modules respectively
allows to get the specific event of an archive stable id related to a given stable id
finally gives access to score

also updated existing tests to use is rather than ok whenever possible

Using while shift will eventually cause an undef to be processed. This
is how the while loop detects a false condition. We cannot lc() an
undef. Do not do this in the while. Only do it in the loop

if biotypes between transcripts differ, add penalty
if biotype groups between transcripts differ, add even more penalty

allows to return protein feature specific attributes for translation rest endpoint

with rest stack trace, \n is ignored and the query looks like columnFROM
it is not going to affect the running of the query, but can be confusing, so adding a space before the FROM

The method was called on the wrong object. Swithced around and tested

'logic_name' can be the analysis' logic_name, or the db name if nothing found
allows to fetch 'low_complexity' regions without knowing that the analysis is seg
only works if no protein_features were added to that translation
mimicks the webcode behaviour like in http://www.ensembl.org/Homo_sapiens/Transcript/Domains?db=core;g=ENSG00000139618;r=13:32889611-32973805;t=ENST00000544455

Nick in Ensembl Genomes has seen an issue with bacteria databases where
we exceed the number of connections on MySQL. As we loop through DBAdaptors
we do not disconnect. That means an ID which appears later on will have
opened all prior databases. The connection is still active. We now
disconnect this.

we have too many reg starting variables to use shortened names

replaced reg with registry for more explicit code

if we use first_registry and last_registry throughout the module, we can probably afford to use registry rather than reg for the simpler cases

helps for consistency across modules
also makes it easier to grep for registry calls, reg is too generic (regulatory, region, registry...)

seq_regon_name would never have worked, so the warn would have ended up as a fail

Simple formatting changes suggested by Bron. Will make the example cut-paste
usable.

Patch submitted by Leo for PGSQL default port number.

We have decided to revert this change. GeneBuilder code has a link to the
existing functionality manifesting itself as subtle silent breakages. The
old functionality has been brought back. Warning added about how possibly
bad using the array from this function is.

Test schemas should not need this. It also gets in the way of SQL
diffs so just ignore it for the moment.

The test schema was out of sync for ages due to it never being patched
using the patch sets. This is no longer the case. We needed a one
shot resynchronisation between the live schema and this test schema. All
test cases have been run and still pass. Assuming the processes
has not destroyed data. Any data changes seem to be related to different
levels of precision being emitted in the files.

Meta coord was updated.