[GPU::DeviceArray] Expand the API of the DeviceArray to ease data transfer and allocations

I was thinking of expanding the API of the DeviceArray class by two functions. Firstly, a member function to download only part of the device data to the host. Secondly, a function to resize the DeviceArray. Expanding the API is motivated by a performance analysis (#4677) we made and to bring the API of the device array in line with STL semantics.

In more detail, the signature of the download function could be:

DeviceArray<T>::download(const T* const device_begin, const T* const device_end, T* host_ptr);

One would pass the two points on the device array from which data should be downloaded and copied and a pointer to the host array at which location data is inserted. At the moment we only have two download functions

/** \brief Downloads data from internal buffer to CPU memory
* \param host_ptr pointer to buffer to download               
* */
void download(T *host_ptr) const;

/** \brief Downloads data from internal buffer to CPU memory
* \param data  host vector to download to                 
* */
template<typename A>
void download(std::vector<T, A>& data) const;

download function that downloads all the data which can be more than necessary.

The resize function is simply:

DeviceArray<T>::resize(int N);

I think implementing a resize function is more involved as it also requires adding another member variable. Currently, the size and capacity of the device array are equal. I think they would have to be different for a resize function to work. What do other people think about this? Does this seem to be a good idea? How could the proposal be improved, and what else do we need to think about? I'd be happy to implement this, but wanted to discuss it first.

Start with the DeviceArray class and its existing download overloads, which are the entry points named in the issue. Review how size and capacity are currently represented before evaluating partial downloads and resize semantics. Done requires an agreed API design and implementation scope; no specific files or tests are identified in the issue.