Add index type template parameter to memory accessor

[taaae]

Things to note/discuss:

• I use IndexType for the dense-matrix accessors as well:

  ginkgo/common/cuda_hip/matrix/ell_kernels.cpp

  Lines 245 to 246 in 741c786

  	using b_accessor = acc::reduced_row_major<2, arithmetic_type,
  	const InputValueType, IndexType>;

  ginkgo/common/cuda_hip/matrix/ell_kernels.cpp

  Lines 300 to 305 in 741c786

  	const auto b_vals = acc::range<b_accessor>(
  	typename b_accessor::dim_type{{static_cast<IndexType>(b.size[0]),
  	static_cast<IndexType>(b.size[1])}},
  	b.values,
  	typename b_accessor::storage_stride_type{
  	{static_cast<IndexType>(b.stride)}});

  It is useful in this line:

  ginkgo/common/cuda_hip/matrix/ell_kernels.cpp

  Line 108 in 741c786

  temp += val(ind) * b(col_idx, column_id);

  But I guess it can be weird from the user's perspective. Like, they define an ELL matrix with IndexType, but suddenly dense matrices passed in the kernel also are getting accessed with this IndexType.

• I also added bunch of asserts, like this one:
  

  ginkgo/reference/matrix/ell_kernels.cpp

  Lines 46 to 48 in 741c786

  	GKO_ASSERT(
  	fits_index_type<IndexType>(num_stored_elements_per_row * stride));
  	GKO_ASSERT(fits_index_type<IndexType>(b.size[0] * b.stride));

  To prevent such overflows:

  ginkgo/reference/matrix/ell_kernels.cpp

  Lines 49 to 52 in 741c786

  	const auto a_vals = gko::acc::range<a_accessor>(
  	typename a_accessor::dim_type{
  	{static_cast<IndexType>(num_stored_elements_per_row * stride)}},
  	a.values);

• Also, the default matrix IndexType is int32:

  ginkgo/include/ginkgo/core/matrix/ell.hpp

  Lines 52 to 53 in 741c786

  	template <typename ValueType = default_precision, typename IndexType = int32>
  	class Ell : public EnableLinOp<Ell<ValueType, IndexType>>,

  while the accessor's internal index type was hardcoded to int64 before this change:

  ginkgo/accessor/reduced_row_major.hpp

  Line 72 in 8e9859e

  using index_type = std::int64_t;

  So after this change, all users of default-constructed matrices silently switch from int64 to
  int32 indexing in these kernels. Do we have cases where people use matrices/operands big enough that int32 would overflow?

• Small note: I use IndexType for strides and lengths as well:

  ginkgo/accessor/reduced_row_major.hpp

  Lines 63 to 64 in 741c786

  	using dim_type = std::array<index_type, dimensionality>;
  	using storage_stride_type = std::array<index_type, dimensionality - 1>;

  ginkgo/accessor/reduced_row_major.hpp

  Lines 151 to 154 in 741c786

  	constexpr GKO_ACC_ATTRIBUTES index_type length(size_type dimension) const
  	{
  	return dimension < dimensionality ? size_[dimension] : 1;
  	}

  It is useful because it turns the 'stored stride type' -> 'kernel index type' cast into a no-op:

  ginkgo/accessor/reduced_row_major.hpp

  Lines 263 to 265 in 741c786

  	const dim_type size_;
  	storage_type* const storage_;
  	const storage_stride_type stride_;

  ginkgo/accessor/reduced_row_major.hpp

  Lines 169 to 173 in 741c786

  	operator()(Indices&&... indices) const
  	{
  	return reference_type{storage_ +
  	compute_index(std::forward<Indices>(indices)...)};
  	}

  ginkgo/accessor/accessor_helper.hpp

  Lines 57 to 60 in 741c786

  	return GKO_ACC_ASSERT(first < static_cast<IndexType>(size[dim_idx])),
  	first * static_cast<IndexType>(stride[dim_idx]) +
  	row_major_helper_s<IndexType, total_dim, current_iter + 1>::
  	compute(size, stride, std::forward<Indices>(idxs)...);

  If the members stayed size_type, that static_cast<IndexType>(stride[dim_idx]) would be a real
  64 -> 32 bit conversion on every single access.

  No similar improvements for dim_type and length(), but I think IndexType fits better there.