tao::get overload ambiguity workaround for Cuda10.2 and GCC9.3.1/MSVC2019

[maudoin]

First, kudos for your nice and clean c++ implementation.
I am currently using Cuda 10.2 (which has bug regarding the std::tuple implementation...) with either gcc9.3.1 and MSVC2019 with c++14 and the samples fails to compile inside a cuda kernel.
Specifying return types to the tao::get methods seems to put too much strain on overloads selection.
This is even worse with Cuda 10.2/MSVC2019 where the move semantic tao::get variant is mixed with other signatures as well. My apologies in advance for the name of the "tao::getMove" function and call I added in the tuple move operator, my first shot at function naming is always bad...
I also fixed two std::move calls that IMHO should be replaced with std::forward.
Best Regards

[d-frey]

I just committed another fix for get(), please check if that already solves your problem or if your issue remains.