BlockOperator direct and adjoint methods: can pass out as a DataContainer instead of a (1,1) BlockDataContainer where geometry permits - #1926

So in #1802 we changed BlockOperator direct (and adjoint) methods to return a DataContainer in the case it would previously return a (1,1) BlockDataContainer. We also changed the range (and domain) to output the required geometry in this case.

In this PR we allow BlockOperator direct (and adjoint) methods to accept both a (1,1) BlockDataContainer or a DataContainer to out where that fits with the range (and domain) geometry. They already accept both (1,1) BlockDataContainer or a DataContainer as an input argument where the domain (and range) geometry allows.

The question is: should a BlockOperator always return a BlockDataContainer or are (1,1) BlockDataContainers an unnecessary wrapper and they should be DataContainers?

In the first case, we should write an as_array() method for (1,1) BlockDataContainers to fix the original CIL-SIRF issue #1455 and probably leave this fix in. In the second case, we leave #1802 as it is and implement this fix.

After discussion with Edo and Gemma we decided that this should go in but that we would still further investigate #1863

@gfardell - do you want to check the adjoint code and approve if you are happy?

We need to decide the default. If no out is provided to direct(adjoint) but it should return a 1 by 1 block data container, should this be a data container -to match the range (domain) - or be a block data container?