Do not rely on implict copy constructors when destructor defined

As a general C++ "rule of three," if one of a copy constructor, copy
assignment, or destructor is defined, all three should be defined. Some
compilers issue warnings if this rule of three is violated.

It is sometimes the case that we define a destructor simply because it
is only valid in the control environment. When doing so, add
implementations for copy constructor and assignment as well.

vtkm/cont/StorageVirtual.h

@@ -33,7 +33,6 @@ class VTKM_ALWAYS_EXPORT ArrayPortalRef : public vtkm::ArrayPortalRef<T>
 
 public:
   ArrayPortalRef() = default;
-  ~ArrayPortalRef() = default;
 
   ArrayPortalRef(std::shared_ptr<vtkm::ArrayPortalVirtual<T>> portal, vtkm::Id numValues) noexcept
     : vtkm::ArrayPortalRef<T>(portal.get(), numValues),

vtkm/filter/FieldSelection.h

@@ -131,8 +131,32 @@ public:
     }
   }
 
-  VTKM_CONT
-  ~FieldSelection() {}
+  // Normally the default compiler construction of each of these would be fine,
+  // but we don't want any of them compiled for devices (like CUDA), so we have
+  // to explicitly mark them as VTKM_CONT.
+  VTKM_CONT FieldSelection(const FieldSelection& src)
+    : Mode(src.Mode)
+    , Fields(src.Fields)
+  {
+  }
+  VTKM_CONT FieldSelection(FieldSelection&& rhs)
+    : Mode(rhs.Mode)
+    , Fields(std::move(rhs.Fields))
+  {
+  }
+  VTKM_CONT FieldSelection& operator=(const FieldSelection& src)
+  {
+    this->Mode = src.Mode;
+    this->Fields = src.Fields;
+    return *this;
+  }
+  VTKM_CONT FieldSelection& operator=(FieldSelection&& rhs)
+  {
+    this->Mode = rhs.Mode;
+    this->Fields = std::move(rhs.Fields);
+    return *this;
+  }
+  VTKM_CONT ~FieldSelection() {}
 
   /// Returns true if the input field should be mapped to the output
   /// dataset.