Due to changes in the structure of the production database, since
release 98 the value of analysis.logic_name corresponding to non-coding
RNA can be either 'ncrna' (which is what we used before) or
'ncrna_species_name'. Change the SQL query used to map RFAM IDs to
Ensembl stable IDs so that it can correctly handle species using the
latter syntax, i.e. human, mouse and zebrafish.

Issue: ENSINT-402

See ENSCORESW-3197. Have to think about the correct way of specifying
where to put that output file though, especially given the parser
doesn't actually delete it after it is done with it.

The initial value of the variable $counter is set to the highest
checksum_xref.checksum_xref_id found if the table in question is not
empty, or 0 if it is. This causes problems if $counter is only
incremented after each use in the input-file loop:
 - for a non-empty table the parser would attempt to re-use an existing
   value of checksum_xref_id for the first entry read from the input
   file. checksum_xref_id is the primary key of checksum_xref so its
   values have to be unique, therefore "LOAD DATA" silently discards the
   offending row;
 - for an empty table we lose one input row as well but it is the SECOND
   rather than the first one. Reason: 0 is not a valid value for
   auto_increment fields in MySQL, resulting in the first row being
   inserted with the first allowed ID value of 1 - which brings us back
   to the previous scenario when "LOAD DATA" attempts to insert the
   second row.

Incrementing $counter before use ought to address both forms of the
problem.

Not used any more + at least partly out of date.

The ontology schema patches have been moved from ensembl/misc_scripts/ontology/sql to ols-ensembl-loader/sql

Uses the same type of SQL SELECT queries as Translation, which makes
sense given how similar they are.

Tested on test-genome-DBs/homo_sapiens/core, works without errors.

Aborts upon encountering a core database missing the 'rnaproduct' table
but that is in my humble opinion very much desired behaviour, as it could
indicate incomplete application of schema patches in the release this
will be included in.

It made recognising incorrect entries needlessly slow

return goes back one frame up the stack
next goes back to the closest frame on the stack that supports the
operation (that is close enough in RefSeqGPFFParser alone)
It works unless I subclass create_xrefs, and then my Hive workers die:

Lost control. Check your Runnable for loose 'next' statements that are
not part of a loop       WORKER_ERROR

- New xref: to a WormBase CDS feature
- Modify WormbaseCElegansRefSeqGPFFParser to serve both kinds of files
- extract a utility method from RefSeqGPFFParser
- xref_config.ini stanza for wormbase_cds
- tests for new functionality

- maintain naming convention: WormBase specific stuff says Wormbase at the front
- rewrite WormBaseDirectParser
- WormBaseDirectParser populates protein_ids
- superclass method to make dependent protein_ids as parent
- tap into UniProtParser
  + also skip EMBL scaffold ids (we can't reliably assign them)
- tap into RefSeqGPFFParser
  + extract a method
- tests for new stuff
  + add %args to parametrise test_parser

Benefits for RefSeqGPFFParser:
RefSeq proteins have coordinates as part of their identity, so we
can't reliably sequence match them, we will also pick up all paralogs.
This change fixes this spurious mapping.
Benefits for UniProtParser:
Not the above: UniProt entries are not tied to coordinates so all
paralogs map to the same entry. We can handle versioning and updates
a bit better: if WormBase updates an entry and a protein id changes but
UniProt doesn't reflect this yet, with the change we will still pick up
the UniProt entry although we can't sequence match any more.

The only part of the xref-mapping pipeline that depended on the
long-deprecated module XML::Simple was TAIROntologyParser - which did
not actually *use* that module for anything. Get rid of the useless
import, thus making it unnecessary for XML::Simple to be mentioned in
the cpanfile.

Useful under the circumstance when the person running the script is not
in fact the RelCo for the next release, as it has already been the case
before. Saves one having to manually reassign all the newly created
tickets to the actual RelCo. Conversely, if it is the same person just
omit the new argument and the RelCo user name will be used to connect to
JIRA.

Note that the function validating user names is only applied to RelCo
ones. This is intentional, JIRA itself will complain if the submitter is
not authorised to create ENSCORESW tickets.

Being able to pass a scalar to e.g. keys was an experimental feature
that was added in Perl 5.14 and since declared failed, thus causing the
script to fail with an "Experimental keys on scalar is now forbidden"
error.