Y25-525 - [BUG] Label printing inconsistency

[KatyTaylor]

N.B. don't fix this for the version of the code using Sequencescape API v1. Move to v2 first (#562)

Describe the bug
Barcode labels printed from two different places are inconsistent, in that one includes the dashes in the barcode, and one doesn't.

To Reproduce
Steps to reproduce the behaviour:

1. Go to homepage
2. Click on button "Register Pre Stamped Tags Lot"
3. Fill in form and submit
4. Fill out "Create Pre Stamped Plate" (top right) form (choose a printer you can access) and submit
5. Re-print the barcode(s) using the bottom left form
6. Compare the two barcode labels printed
7. Looking at the actual barcode (not the text), one includes dashes in the barcode and one doesn't. e.g. SQPU-308742-T vs SQPU308742T (or

Expected behaviour

Barcode should include the dashes. Check this also works for '384' lots.

Screenshots

[BenTopping]

I think this is a Sequencescape v1 vs v2 discrepancy for Lots. We should be able to fix it in #563

When printing during "Create Pre Stamped Plates" we use this route, which when printing uses v2 qcables which pass in human_readable barcode attributes to the BarcodeSheet::Label.

When printing using the Reprint function in the bottom left we use this route which just passes the prefix and number - not a human_readable barcode attribute. This is due to the lot (and qcables) being v1 objects at this point and not having available attributes like human_readable. This then causes Gatekeeper to have to generate the Sanger barcode given the prefix and number here. This isn't creating the label correctly. It don't think this is worth fixing in the SBCF library.