Avoid piracy and racey method shadowing

[jpsamaroo]

This PR implements a mechanism for utilizing the selected backend to create a dispatchable key (turning "cuda" into Val{:cuda}()), so that extensions do not need to shadow/pirate JACC's own methods. This should make it safe to load CUDA, AMDGPU, and oneAPI all at once (or any such combination), yet have things still dispatch correctly based on the selected backend.

~Unfortunately, this cannot work for JACC.Array as-is, because extensions are loaded after __init__ is called. So instead, I propose moving the setting of JACC.Array into an init() function that users must call to initialize JACC. There is not really any nice way to do this that I can think of - maybe if module property access becomes something we can control (like how we can overload getproperty), then it will be possible to remove the need for init().~ Fixed!

Although this does work for using AMDGPU, JACC for me locally, I still have to wire up the tests for this, and I haven't tested any of the functionality (as my ROCm libraries are a mess on my local system). ~Hence this is currently a draft PR.~

[jpsamaroo]

Note: this is an alternative to https://github.com/JuliaORNL/JACC.jl/pull/114/, which is similar in scope, but also does not resolve the issues around JACC.Array. I think this PR's approach is a bit simpler, and doesn't require eval'ing another global into the JACC module (which is what prevents JACC from being precompile-able).

[jpsamaroo]

...and I just realized that it's also an alternative to https://github.com/JuliaORNL/JACC.jl/pull/86, which I think goes much further to resolve the issues with JACC.Array and is a more correct solution.

[williamfgc]

Test this please