Add new support for repack archive routes

Problem

As shown in https://gitlab.cern.ch/cta/operations/-/issues/1310 and other issues, there is currently no way to separate repack archive requests from user archive requests regarding the destination tape pool.

This means that, during a repack, old files that are being queued and written to a new tape may get mixed with new files that have just been queued by users of the same VO.

This is an undesirable behaviour that may end up causing issues (for example performance) when reading very different types of files from the same tape. It is also the latest blocker from completely separating the CTA operation domain from user domain.
More info can be found here on slide 23:

https://indico.cern.ch/event/1353243/contributions/5846588/attachments/2821114/4930135/Improving%20CTA%20performance%20by%20splitting%20user%20and%20repack%20scheduler%20backends%20(3).pdf

Solution

Part 1 (CTA catalogue)

Add a new REPACK_TAPE_POOL_ID column to the ARCHIVE_ROUTE.
This column should be optional (nullable), be a foreign key to TAPE_POOL_ID and UNIQUE (together with STORAGE_CLASS_ID).

Part 2 (CTA code)

Create the new cta-admin options to set/modify the REPACK_TAPE_POOL_ID column.
Modify the maintenance process code to pick up the REPACK_TAPE_POOL_ID value (instead of the default one) when archiving repack files.
- If the (optional) repack tapepool value is not defined, use the default TAPE_POOL_ID.
- Parts of this code can be found here: