Added a check to test the UNIQUE KEYs

[muffato]

See https://www.ebi.ac.uk/panda/jira/browse/ENSCORESW-3564 : UNIQUE KEYs that comprise a column that is NULL-able allow duplicated rows if they contain one NULL.
This is not something we want in the Compara schema, and it's caused some issues with the theobroma_cacao renaming this release, so here is a new DC to check those. It's structured the same way as ForeignKeysCompara and is quite generic. It could probably be applied onto other database types, should people need to.

[coveralls]

Pull Request Test Coverage Report for Build 1471

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 95.867%

---

Totals
Change from base Build 1469:	0.0%
Covered Lines:	1879
Relevant Lines:	1960

---

💛 - Coveralls

[james-monkeyshines]

This looks fine, and I take you point about having methods to parse SQL. However, was there a reason why you didn't query the mysql schema to get the unique keys? I think that'd tend to be a bit more robust, e.g.

select
  table_name,
  index_name,
  group_concat(column_name order by seq_in_index) as index_columns,
  index_type
from
  information_schema.statistics
where
  table_schema = database() and
  non_unique = 0 and
  index_name <> 'PRIMARY'
group by table_name, index_name, index_type
order by index_name;

[muffato]

Yes, good point, I could have queried the list of unique keys from the schema itself. I think I was worried the database wouldn't have the correct schema in some situations. We had an issue last release with MySQLTransfer because it copies the data and the schema, and our source database was on an older version of the schema, so I preferred taking table.sql as the truth.