Solve Creational Conundrum in InstrumentTree and Related Components

[OwenArnold]

For the following discussion I use Instrument Collection to refer to InstrumentTree, DetectorInfo and SpectrumInfo

• InstrumentTree, DetectorInfo and SpectrumInfo should not know how to create each other. That would severely limit the ability to test each one in isolation. Mixing creational logic with domain logic is also not wise.
• Taking SpectrumInfo as an example, the held DetectorInfo must exist and be in a valid state by the time the SpectrumInfo constructor completes. We do not want to leak the encapsulated knowledge we see currently done in the Mantid framework, where clients are forced to very that an object isValid or isInitialized before calling it.
• Seemingly at odds with the above, from the MPI perspective, ranks are specified per SpectrumIndex, and that is a key part of the InstrumentTree redistribution. The procedure for making the instrument collection, involves extracting those spectrum indexes that should reside on a given rank and creating an instrument collection from scratch around it. This supposes that creation happens in the reverse order that we expect, we know the spectrum indexes, so we create the SpectrumInfo first, and then we create the other held bits.

This is a necessary part of mpi support

[OwenArnold]

Another interesting feature to this mentioned by @SimonHeybrock is how updates may work #41 for example updates to a DetectorInfo would need to propagate to any utilising SpectrumInfo