Add tus host config

[Caushi]

Draft until a bfabricpy release is out and the XSD change has been rolled out to the fleet —
pairs with fgcz/BioBeamer#25 and fgcz/BioBeamerLauncher#6.

What this adds

xml/BioBeamerTus.xml — one host, testhost_tus, using the new tool="tus" backend.

Why a separate file rather than an entry in BioBeamerTest.xml

The config XML is read by every host, but the XSD that validates it ships per BioBeamer
version. So the moment a tus_* attribute appears in a shared file, every host still pinned to an
older version fails validation on every run — including robocopy hosts that have nothing to do with
tus.

Verified: this file validates against the new XSD and fails against the old one.

Keeping the tus host in its own file (pointed at by its own launcher.ini xml_file_path) means
nothing the fleet reads is touched. Before these hosts can be merged into the shared configs, the
xs:anyAttribute forward-compatibility fix in fgcz/BioBeamer#25 has to be back-ported and rolled
out — after which unknown attributes stop being a fleet-wide breaking change.

The host

Points at the local dev stack: tus endpoint localhost:1337/files, application 417 (an import
application on storage 15, the TUS-enabled storage), container parsed from the path.

tus_container_pattern="p([0-9]+)" — the container comes from the file path, not the host, because
one instrument writes data for many projects. There is deliberately no fallback: a path with no
recognisable container fails the run rather than guessing.

pattern includes bin so that nested files inside a .d bundle (sub/deep.bin) are not filtered
out — a partially-filtered bundle cannot be uploaded as a single directory entry, which is what
preserves the internal structure as resource names.

Before real use

source_path, tus_endpoint and applicationID are dev values and must be set per instrument.
version must point at a BioBeamer ref that contains the tus backend.