Move alpaka vecmem logic to functions

[StewMH]

Templated functions returning shared_ptrs that create vecmem::hip::device_memory_resource etc. Note that because of the casting to a derived class this has to be done via pointers.

@krasznaa think this might be along the lines of what you were thinking of?

Waiting for a substantial PR from @CrossR first

[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

[krasznaa]

No, not really...

I'm imagining a "simple" class like the following:

namespace traccc::alpaka::details {

class vecmem_objects {

public:
    ...
    vecmem::memory_resource& host_mr() const;
    vecmem::memory_resource& device_mr() const;
    vecmem::memory_resource& shared_mr() const;
    vecmem::copy& copy() const;

private:
    struct impl;
    std::unique_ptr<impl> m_impl;
};
}  // namespace traccc::alpaka::details

I.e. make an opaque class (using Pimpl) that creates (and owns) some vecmem objects, and gives access to these through their generic interfaces. Then clients would just instantiate such an object themselves. Like:

traccc::alpaka::details::vecmem_objects vo{};
...
vecmem::vector<float> foo(&(vo.host_mr()));
...

The goal is to remove all Alpaka related preprocessor statements from the public interface of this library. 🤔