Refactoring the new Async mode additions

[JuanGonzalezCaminero]

The goal of this PR is to adapt the new Asynchronous AdePT components to the way the library is structured. This involves keeping a clear separation between AdePT and the integration layer.

Main changes:

• Remove AdePTConfiguration from the integration layer.
  This is an utility class which holds the AdePT configuration for a run, it is part of AdePT and independent from the integration layer. However the new AdePTConfiguration::CreateAdePTInstance is compiled as part of AdePTG4Integration. In practice, this isn't a change from the previous implementation, where the integration layer has the responsability of initializing AdePTConfiguration, and also of passing the values in AdePTConfiguration to AdePTTransport.
  This will be changed in this PR, by introducing a new AdePTTransport constructor which takes an AdePTConfiguration instance as an argument. Now the integration layer is only responsible of initializing AdePTConfiguration.

  • AdePTConfiguration will now also store the number of threads, which is used to compute the number of tracks and step slots allocated to each thread in synchronous mode. By doing this, we will also remove the need to store the number of slots per thread as static inline variables in AdePTTransport. This was done because in Geant4 we can only get the correct number of threads from the master, as the workers will report 1, thus we can only compute the space per thread from the master. However this is a G4-specific requirement that is not related to AdePT, so now, instead of doing that, we store the number of threads as a static inline variable in AdePTTrackingManager, on the integration side, which each thread then passes on to AdePTConfiguration.

• Remove the AdePTTransportFactory method in favour of using the AdePTTransport constructor.
  This method is currently implemented as a free function that is part of the integration layer. It is called from AdePTConfiguration::CreateAdePTInstance.
  In principle, it wouldn't be an issue to keep one factory per transport backed, per integration layer, however at least for the synchronous backend there seems to be little reason to use a factory method instead the AdePTTransport constructor.

• Implement a constructor in AdePTTransport which takes an AdePTConfiguration instance as an argument.
  In the current implementation, the integration layer is supposed to initialize AdePTConfiguration and also to pass those values on to AdePTTransport. With this change, the integration layer only needs to initialize the configuration.

• Move the instantiation of ShowerGPU back to to AdePTTrackingManager.cu.
  We need to instantiate ShowerGPU in a .cu file so that this function is compiled by nvcc. This is a necessary evil, and needs to be done in the integration layer since AdePT is a header-only library. This function has currently been moved to AdePTTransport.cu, which lives on the integration layer. As with the AdePTConfiguration change, in practice the integration layer is still responsible of doing this instantiation, it just lives on a different file. Since AdePTTransport.cu is not actually related to AdePTTransport, and it is AdePTTrackingManager that calls this function, I believe it is less misleading to keep this in AdePTTrackingManager.cu.

• Remove the functionality to keep tracks returned by AdePT on host.
  There are two main reasons for this:

  • This functionality is meant to keep loopers returned from AdePT on host, however it doesn't distinguish between loopers and particles that simply stepped outside of the GPU region. This may be implemented in the future in a similar manner, by having a special ID for loopers if needed.
  • However in the future we may need to keep unique IDs for GPU tracks, in order to be able to identify them on host, so we can't use the ID field for this.

• Remove the call to the user stepping action from the tracking manager.

  • G4SteppingManager::Stepping already calls the stepping action

[phsft-bot]

Can one of the admins verify this patch?