Signed-off-by: Karl Palmen <karl.palmen@stfc.ac.uk>

The files are yet to be renamed

Signed-off-by: Karl Palmen <karl.palmen@stfc.ac.uk>

Presumably there were initial concerns that RVO would not take place. As a result the API for the BoundingBox is strange, and I do not want to replicate that in the new API for ComponentInfo. One thing that tripped me up was the fact that the ObjComponent::getBoundingBox was reassigning the input arg, not calling ::grow, for example, there is also some mess around the coordinate system which is stripped from the input. Eventually I would like to remove the reference BoundingBox argument altogether, but for the moment I keep it for backwards compatibility.

This is something that was done in Instrument 1.0 and as far as possible I have made backward compatible in the Geometry::ComponentInfo layer. Since shape returns a const ref, I've exposed the hasShape method publicly so that clients may check a shape before extracting without introducing uncessary slowdown by checking it as part of the shape() method.

This is not yet optimised at all

Not re-routed via Component yet.

A lot of this was testing aspects that are already covered by Beamline::ComponentInfo and ince API::ComponentInfo is pass-through in as many places as possible, this was not adding any useful value.

Internally store data as shared_ptrs. That way the visitor can be copied cheaply.

ExperimentInfo::getInstrument is slow otherwise. This is a problem,
since getInstrument is called by getDetector, i.e., for every pixel in
an instrument.