Check VecGeom BVH device pointers at setup and run time

[sethrj]

This is an attempt to truly nail down the failure mode for #1462 . It adds a kernel launch that simply copies dBVH, the global inline BVH device pointer, back to the host. It also adds code for comparing it against the result of cudaMemcpyFromSymbol, which in all the tested configurations (combinations of static/shared) returns a null pointer, and against the actual VecGeom-allocated device pointer (which depends on https://gitlab.cern.ch/VecGeom/VecGeom/-/merge_requests/1239).

If the kernel-returned dBVH is a null pointer (or one inconsistent with the VecGeom-returned pointer if available), we print an error log message; otherwise we print a debug message. A new assertion in the BVH navigator also checks for some additional null pointers.

[drbenmorgan]

I can only really comment on the CMake side and use of the new VECGEOM_BVHMANAGER_DEVICE symbol that'll come from upstream. These look o.k., as the checks/tests look to protect against the case where this won't be available in older versions.

I guess the only other thing is whether it's possible (without significant effort) to create a build setup/environment that would reproduce the issue, but that's maybe for when we've nailed down the cause(s) better?

[github-actions]

Test summary

 3 371 files   5 194 suites   3m 52s ⏱️
 1 577 tests  1 549 ✅ 28 💤 0 ❌
17 384 runs  17 318 ✅ 66 💤 0 ❌

Results for commit 09901ed.

[sethrj]

Ping @esseivaju @pcanal @mrguilima , can one of you take a look at this and approve? It seems like @esseivaju already confirmed it does the job of telling us that the BVH pointer is wrong...

[esseivaju]

LGTM