KokkosSparse_spmv_struct_tuning: add lambda guard

[ndellingwood]

Kokkos does not enable lambdas by default when Cuda is enabled.
This test was using lambdas without proper guards, this PR adds guard.
Detected during tpl spot-check nightly testing.

[ndellingwood]

Failing cuda build now passes tpl spot-check

[ndellin@kokkos-dev-2 cmTestAllSandia-tpls]$ ../../scripts/cm_test_all_sandia cuda --spot-check-tpls
Running on machine: kokkos-dev-2
WARNING!! THE FOLLOWING CHANGES ARE UNCOMMITTED!! :
 M perf_test/sparse/KokkosSparse_spmv_struct_tuning.cpp
?? scripts/cm_test_all_sandia-backup

Repository Status:  04795922172fb988ad9141473fd95ab7933ad0de Merge pull request #637 from kokkos/testall-cudauvm


Going to test compilers:  cuda/10.1
Testing compiler cuda/10.1
  Starting job cuda-10.1-Cuda_OpenMP-release
kokkos options: 
kokkos devices: Cuda,OpenMP
kokkos cxx: -O3 -Wall -Wshadow -pedantic -Werror -Wsign-compare -Wtype-limits -Wuninitialized 
  PASSED cuda-10.1-Cuda_OpenMP-release
#######################################################
PASSED TESTS
#######################################################
cuda-10.1-Cuda_OpenMP-release build_time=158 run_time=180

[ndellingwood]

For reference, this addresses failures detected during testing of #554 and the failing nightly build https://jenkins-son.sandia.gov/job/KokkosKernels_KokkosDev2_SPOTCHECK_TPLS/1/consoleFull

[lucbv]

So it would have been nice to tell me this and not merge it immediately as I have this fix in my PR and I'm only waiting for bowman to finish to run the spot-check, already have kokkos-dev and white done. Now I need to rebase and rerun everything I guess...

[ndellingwood]

@lucbv it's a oneline change, if you pattern match in your PR there should be no merge conflict and no need to rerun testing.

[lucbv]

@ndellingwood my change actually fixes the issue by implementing a functor that avoids having to guard the test hence making it run on more configuration so we have better testing...

[ndellingwood]

@lucbv has functor implementation within #618 , we talked and since this PR was a one line change simply ignoring this change when resolving potential merge conflicts in his PR should not require rerunning tests (as that will preserve his PR as-is, which he is testing)