atomic_fetch_add fix for Kokkos::Serial

[ndellingwood]

Casting required when passing '1' as the increment argument to Kokkos
for cases where the View's data_type is not an int

[ndellingwood]

These type of changes are needed for the next promotion of kokkos and kokkos-kernels.
Compilation errors occur when a View's value_type does not match the increment '1' (which is treated as int) during atomic_fetch_add. Exposed when testing Serial backend.

[mndevec]

@ndellingwood
Did the interface for atomic_fetch_add change, or was this en error we fail to capture previously?

[ndellingwood]

@mndevec
There were some changes to the implementation of the Serial Atomics in this PR that recently went into kokkos - kokkos/kokkos#1426

In the Kokkos promotion issue kokkos/kokkos#1413 @ibaned gave the following explanation:

this is because we've been presenting users with an interface that is more convenient than the general case should allow. Basically the constant 1 is by default typed as an int, so the compiler can't determine if the user wants to do an atomic_fetch_add on an int or on the other type (the type of the pointer). I recommend replacing all these calls which have 1 as the second argument into calls to Kokkos::atomic_increment. Calls with more complicated second arguments should cast them both to the same type or specify the template parameter explicitly.

[ndellingwood]

@mndevec I can resubmit a PR with the atomic_fetch_add templated on the proper type if that seems cleaner.
I did not use atomic_increment since it returns void and I think in all (nearly all) cases here it looked like the code depended on the return value from atomic_fetch_add prior to increment.

[mndevec]

This looks good. I am just trying to see whether these cast affects the performance. I will approve it as soon as it is done.
Thanks Nathan!

[ibaned]

@mndevec the casts were already happening explicitly before, the change just forces you to declare it explicitly. casting a constant like 1 to a type is a zero-cost operation.

[mndevec]

@ibaned
I experimentally confirmed that it does not affect the performance.
However, some push in kokkos develop branch seems to be causing about 2.5x slowdown on an SPGEMM kernel. I am trying to track down the commit.

[mndevec]

This will be fixed in Kokkos. So this won't be merged.