BibUpload: duplicate subfields in bibrec_bibxxx

* bibrec_bibxxx tables are not designed to support
  duplicate subfields within the same field of a record.
  However this was not enforced in the table constraints.
  Amends bibuplod to not generate duplicate rows in
  bibrec_bibxxx tables and corrects these table constraints.
  (closes #1714)

Signed-off-by: Samuele Kaplun <samuele.kaplun@cern.ch>
Yes, it is necessary to do full table scan to detect dupes, but the creation of a temporary table copy is also expensive... and I expect it to be considerably more expensive in my eyes, which is why I said that doing things *in situ*, as in Sam's original approach, seems preferable to me.   

Let's see the difference:

```console
In [23]: run_sql("SELECT COUNT(*) FROM bibrec_bib10x")
((1498327L,),)

In [24]: %timeit res1 = run_sql("SELECT id_bibrec, id_bibxxx, field_number FROM bibrec_bib10x GROUP BY id_bibrec, id_bibxxx, field_number HAVING COUNT(*)>1")
1000 loops, best of 3: 528 us per loop

In [25]: %timeit res2 = run_sql("CREATE TEMPORARY TABLE tmp2 SELECT DISTINCT * FROM bibrec_bib10x")                                                                     
1 loops, best of 3: 3.98 s per loop

In [26]: run_sql("SELECT COUNT(*) FROM bibrec_bib10x")[0][0] - run_sql("SELECT COUNT(*) FROM tmp2")[0][0]                                                               
43L
```

Seems to confirm the expectations.

(Note that the number of affected rows on most installations should be close to zero; much less than the total number of rows.  If DB tables are nicely cached on the DB server filesystem, then `SELECT... GROUP BY...` should be preferable to doing temporary table copies.)