fix: regression in non-fast scalar indexing support

[avik-pal]

fixes #759

• Jacobian support for GPU Arrays has been restored
• ForwardDiff.gradient now supports GPU Arrays

cc @ChrisRackauckas @devmotion

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.07%. Comparing base (fbf48ae) to head (11540a0).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #760      +/-   ##
==========================================
+ Coverage   89.58%   90.07%   +0.49%     
==========================================
  Files          11       12       +1     
  Lines        1008     1038      +30     
==========================================
+ Hits          903      935      +32     
+ Misses        105      103       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ChrisRackauckas]

Does this not have an inference issue due to losing static information about size? I would think this needs to be ntuple unless it can prove things about size.

[ChrisRackauckas]

It would still be type-stable, it would just have dynamism in the function that would slow it down a bit during the broadcast.

[avik-pal]

Here the chunksize is already an Int, so I don't think we will have any benefit of using an ntuple

[devmotion]

@avik-pal one final question: why is it necessary/useful to support both GPUArraysCore 0.1 and 0.2? Only GPUArraysCore 0.2 is tested:

Suggested change

	GPUArraysCore = "0.1, 0.2"
	GPUArraysCore = "0.2"

[KristofferC]

In #472, the seed! (etc) functions were written in a generic (non-typespecific) way that should have supported GPU arrays. This PR adds further specializations to seed! for some specific types by using extensions. But why does the previous approach not work anymore? That one seemed better since it supports non-fast scalar indexing for arrays that are not GPU arrays.

Has it been properly explored if the existing functions can be written in an alternative way that would support both fast and non-fast scalar arrays with the same generic code (which would avoid any new extensions)?

Edit: I had missed that #739 reverted some of #472.