Small fixes in cones and trackingHT

[valeriaRaffuzzi]

Two small fixes:

1. Cones throw a fatal error if the two bases (which define the orientation of the cone) have different signs. This was the case even when one the bases was zero. Now, one of the two is allowed to be zero.
2. HT would throw a fatal error if the tracking method selection happened on a particle in void (because this means a material XS lookup in void was attempted). Now ST is chosen if the particle is in void.

[ChasingNeutrons]

I'm amazed we hadn't seen this before. I'm curious whether this is the best place to put it rather than in the database? Putting it in the database might make for a tidier transportOperator, but might have some code duplication across different databases.

[valeriaRaffuzzi]

It's not a common problem because it can only happen if particles are born in void, and ST and DT already had checks to make sure that this is ok.
I think adding the check to the tracking operator rather than the database is ok. In the database the only thing you could do is set all the xss to zero, but that might give you troubles somewhere else.

[ChasingNeutrons]

Surely in getTrackMatXS one can have a void check resulting in xs = 0 and an early return? I'm probably not thinking things through though.

[valeriaRaffuzzi]

That function is still called from multiple places.. It should never be called in void from anywhere else, but I think it's still neater to add the check in the transport Operator. Otherwise for consistency we should remove the void checks from DT and ST as well and add more checks in the DB, which would be messier.