fix: dtype inference in new_known_scalar

[pfackeldey]

closes #577

if a 0-dim array is passed to new_known_scalar the dtype was inferred to be np.dtype(type(array(...))) which results in object dtype. This PR directly uses the dtype of the input arg if it has a dtype attribute, which is true for array types.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.10%. Comparing base (8cb8994) to head (6062dc7).
Report is 256 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #578      +/-   ##
==========================================
- Coverage   93.06%   92.10%   -0.97%     
==========================================
  Files          23       24       +1     
  Lines        3290     3598     +308     
==========================================
+ Hits         3062     3314     +252     
- Misses        228      284      +56     

☔ 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.

[pfackeldey]

Needs #579 to fix the awkward-main ci test

[pfackeldey]

ugh... there seem to be the expectation of dask-awkward that a 0-dim typetracer array is always promoted to a length-1 layout. This is something that does not happen with every other array type. I explicitly fixed this in awkward recently: scikit-hep/awkward#3469 (comment), but dask-awkward seems to rely on it...

(needs #580 to be fixed)