Workaround for nvcc generating copy constructors for classes without ODR-use

[PhilMiller]

What Needs to be Done?

            instantiation of class "std::unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc> [with _Key=std::string, _Tp=std::unique_ptr<vt::vrt::collection::storage::StoreElmBase, std::default_delete<vt::vrt::collection::storage::StoreElmBase>>, _Hash=std::hash<std::string>, _Pred=std::equal_to<std::string>, _Alloc=std::allocator<std::pair<const std::string, std::unique_ptr<vt::vrt::collection::storage::StoreElmBase, std::default_delete<vt::vrt::collection::storage::StoreElmBase>>>>]" 
            implicit generation of "vt::vrt::collection::storage::Storable::Storable(const vt::vrt::collection::storage::Storable &)" 
            implicit generation of "vt::vrt::collection::Migratable::Migratable(const vt::vrt::collection::Migratable &)" 
            implicit generation of "vt::vrt::collection::Indexable<IndexT>::Indexable(const vt::vrt::collection::Indexable<vt::Index2D> &) [with IndexT=vt::Index2D]" 

That leads down a rabbit hole where nvcc generates a call to the deleted copy constructor for unique_ptr and then fails the compilation. Making any of those classes that mention implicit generation of their copy constructor non-copyable by saying e.g. Storable(Storable const&) = delete; suppresses that misbehavior.

Seen with nvcc from CUDA 11.7

[PhilMiller]

There are a few other occurrences of std::[unordered_]map<Foo, unique_ptr<Bar>> in our code, but they all lie in non-template classes that aren't subject to this bogus implicit generation, or are a local variable in a member function, and so not a member to be copied.