Add custom thrust/cub namespace when it is supported

[yhmtsai]

This PR allows ginkgo to add custom namespace wrapper around thrust and cub.
We had the issue that ginkgo-alone perform correctly, but some thrust routine is hanging when linking with the other libraries also using thrust.
Ths similar experience had described in NVIDIA/cub#545
Some similar issues may be solved when the thrust is 1.17.2 or 2.1+ (NVIDIA/cub#572), which embeds all architecture in the namespace.
We always use thrust shipped from the cuda Toolkit, and cuda 11.6 (11.6.2 uses thrust 1.15) starts to accept the THRUST_CUB_WRAPPED_NAMESPACE

I put it as gko such that we do not need to use THRUST_NS_QUALIFIER as namespace, which is not defined before supporting custom namespace.
if we need to forward declare something without thrust header, we will need to add ginkgo macro to help that. (currently not neccessary)

Also, when thrust is shipped by CCCL, there is an issue missing inline with host compiler from NVIDIA/cccl#1922.
when using host compiler to compile thrust with custom namespace, it may lead cub::Debug multiple symbols or definition. It does not face the issue without custom namespace though. I avoid them now by ensuring executor.cpp does not include thrust header.

We enable it when the custom namespace supported

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.57%. Comparing base (681caa0) to head (96c9796).
Report is 4 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1730      +/-   ##
===========================================
- Coverage    90.94%   89.57%   -1.38%     
===========================================
  Files          782      782              
  Lines        63297    63527     +230     
===========================================
- Hits         57564    56902     -662     
- Misses        5733     6625     +892     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[upsj]

IMO we should always enable this if it is supported by the Thrust/rocThrust version we found. If we disable it by default, it may break people's code, I don't see a downside to enabling it.

[nbeams]

Also, minor fix: "when the other libraries also uses thrust" --> "when the other libraries also use thrust". And maybe instead of "break", we should say "conflicts"?

[yhmtsai]

I am not too confident about all thrust version always properly respect the custom namespace
like cccl inline issue from host compiler and rocThrust only implement it in half way for several versions.
I think enabling them by default but facing some compiling issue then user turn it off, which is somehow better than hanging somewhere else then taking long time to acknoledge the issue actually from thrust in my mind now.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud