Add S28r1 test

See merge request !108

Removed patched packages from DaVinci, to clean up for the new stack release.

See merge request !102

Fix TurboCache compilation

See merge request !87

Fixes for Tesla productions under Stripping28

See merge request !84

Port Turbo MC fixes for Stripping 28

See merge request !61

This fix is implemented more cleanly in the combination of LHCb!571 and
Analysis!108. This specific commit is a shorter workaround, intended for
deployment as part of DaVinci patch releases for Stripping26 and
Stripping28.

Tesla can then mimic the behaviour of a Stripping microDST writer, by
saving a filtering copy of /Event/MC/{Particles,Vertices} as
/Event/Turbo/MC/{Particles,Vertices}.

Similar to the existing CopyParticle2MCRelations cloner, but it
specialises the cloner template that takes the relations tables
locations rather than the particle locations. This is useful when you
want use existing relations tables made from generic containers of
ProtoParticles.

In the case where the user only wants the relations and MC particles
cloned, and not the (proto)particles, the cloner should be allowed to
just take the (proto)particles from the 'original' location, and should
not force the user to have used the microDST cloners on them beforehand.

Before this commit, PersistReco objects were linked in such a way as to
mimic the output of Brunel, e.g. linking ProtoParticle objects to
`Rec/ProtoP/Charged`.

Now, the Brunel locations are namespaced under a configurable RootInTES.
This allows Turbo and PersistReco to live entirely under one location,
`/Event/Turbo` by default, which should allow a more peaceful
co-existence between Turbo+PersistReco and Brunel output.

This commit moves towards allowing end-user Turbo configuration to more
closely resemble that for a microDST, i.e. setting `InputType = 'MDST'`
and `RootInTES = '/Event/Turbo'`.

The default list of the MC associator (ChargedPP2MC) contains the
default Brunel output locations, like Rec/ProtoP/Charged, but the
PersistReco links will populate these locations with PersistReco
objects. Because we already explicitly add the unpacked PersistReco
locations to the associator's input list, there's no need for the
associator to also run over the Brunel locations.

Can cause confusion (for software and for users) later down the line if
'pure' Turbo is mixed with PersistReco.

Otherwise the MC relations aren't packed, because they don't exist when
the packer runs. D'oh!

Doesn't always live in Trigger/RawEvent, such as after Brunel
processing.

Using `findFirstRawEvent` assumes that the raw bank lives in the same
location as the TCK, which is not guaranteed.

Such caching prevents decoder algorithms from using two separate raw
event locations.

Imagine an algorithm calling `findFirstRawBank`, and the last location
in the list of locations to search contains to requested bank, such that
the last location is cached. A subsequent call to `findFirstRawEvent`
will then return the cached location, even if the first location exists
(it just doesn't contain the raw bank requested during the call to
`firstFirstRawBank`).

A concrete example where this can happen is in PersitReco processing,
where the PersistReco object live in separate raw bank to the TCK, and
where both banks are required by the HLT decoder.