Apply patch_96_97_{c,d,e}, insert the necessary data into
homo_sapiens/core.

Three separate patches here:

1. Create Create tables for RNAProduct. Basically renamed copies of
Translation tables "translation" and "translation_attrib" plus a
new column rnaproduct_type_id, complete with a corresponding table
rnaproduct_type, which is used to distinguish between RNA-product
types;

2. Add type RNAProduct to object_xref.ensembl_object_type. This is
needed to support e.g. miRBase xrefs for microRNAs;

3. Add type rnaproduct to stable_id_event.type. This is needed to
support mature RNA products in stable-id mapping.

Quote noisy strings properly + avoid double-sigil dereferences.

Properties of specific types of mature RNA products such as microRNAs
are stored in the database as attributes (so that we needn't add
type-specific columns to the rnaproduct table) but have shorthand
accessors such as MicroRNA::arm() backed by cache member variables
in the API (for convenience and speed). In order for this to work
properly we have to push possible changes to the cache variables back
to attributes before they are stored in the database - which is what
this method does.

The synchronisation code itself is generic and has been implemented
in the superclass. Specialisation is handled by class-specific mappings
between member names and respective Attribute codes, provided
by RNAProductTypeMapper.

Limitations:
 - at present there can only be either zero or one target attribute;
   having many attributes with the same code results in an exception
   because we do not know which one(s) to update. In the future we might
   have to extend the mapping syntax to support multiple attributes, for
   now however (i.e. for microRNA arms) we do not need it;
 - chances are things will break badly if we fetch a MicroRNA object
   from the database, change the arm and push it back. Right now this is
   not a problem because RNAProducts do not support database updates at
   all, then again should we want to support them we will have to check
   how AttributeAdaptor handles updates of existing objects (as well as
   the same for DBEntryAdaptor, as a matter of fact).

On the one hand there seems to be no good reason for a MicroRNA object
having multiple arm attributes, on the other hand simply taking the
first one in the event of it happening may not even return the same
value every time (it depends on a lot of factors, from the
implementation details of AttributeAdaptor up to and including the
underlying database system). There was a warning but who reads those
anyway. Just throw an exception instead, if someone decides to allow
such a case they can always catch it.

Doesn't really matter since this xref was processed entirely offline -
but just in case.

Previously, get_all_Attributes() would throw an exception in the event
of absence of both the local attribute cache and the adaptor link. That
was not entirely correct because a locally created RNAProduct object
which has not been assigned any attributes would look exactly like that.
get_all_DBEntries() got that right so let's follow its example.

Having carefully analysed miRBase data for mature microRNA products
corresponding to stem-loop sequences already present in Ensembl, I
confirm that the calculation of their start and end in genomic
coordinates is indeed correct for when the stem loop originates from
both forward and reverse strand.

The type in this case is expressed using human-readable code, which is
then translated to numerical ID using data from the rnaproduct_type
table.

More useful, for instance for the upcoming implementation of
Transcript::get_all_RNAProducts() with type filtering. Drawback: must do
a join between rnaproduct and rnaproduct_type on all queries so that
RNAProductAdaptor has got something to put in this field.

Complete with relevant updates to RNAProductTypeMapper and its tests.

This will facilitate reusability because this bit of code will be the
same regardless of the SQL query invoked by the sth.

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.

There is now a dedicated class, Utils::RNAProductTypeMapper, which
provides type_id<->class_name mappings to both RNAProduct constructor
(with the side bonus of no longer having to set the type ID in the
constructor of each subclass) and RNAProductAdaptor. The latter will
likely be used more frequently than the former, therefore the default
map uses type IDs as keys; the reverse map is only generated the first
time it is needed.

In addition to the constructor, the RNAProductTypeMapper.pm defines a
function called mapper() which provides a singleton instance of the
mapper object.

The mappings are hardcoded instead of being retrieved from the database
because the latter could in principle result in execution of arbitrary
code.

Some tests have been defined as well.

1. List of arguments passed to the constructor now references the
superclass (a'la Feature class hierarchy) instead of listing them
explicitly.

2. Arm documentation now correctly lists values this property can take.