fix: ak.Record dict constructor should retain type.

[jpivarski]

This correction has no effect on the value semantics, just the type semantics:

>>> j1 = ak.from_numpy(np.empty(0, np.int32))
>>> ak.Record({"d": j1})
<Record {d: []} type='{d: var * unknown}'>

becomes

>>> j1 = ak.from_numpy(np.empty(0, np.int32))
>>> ak.Record({"d": j1})
<Record {d: []} type='{d: 0 * int32}'>

In a sense, it also provides symmetry between ak.Array and ak.Record, in that they both have this "Pandas-style" constructor now, but since it's a distinction in values for ak.Array but only types for ak.Record, the effect is a little different.

Anyway, it's nice to get this in before the API freeze because this does change the API.

---

📚 The documentation for this PR will be available at https://awkward-array.readthedocs.io/en/jpivarski-ak.record-constructor-should-retain-type/ once Read the Docs has finished building 🔨

[codecov]

Codecov Report

Merging #1981 (86d4e29) into main (5b754e3) will increase coverage by 0.09%.
The diff coverage is 90.09%.

Additional details and impacted files

Impacted Files	Coverage Δ
src/awkward/operations/ak_all.py	96.15% <ø> (ø)
src/awkward/operations/ak_any.py	96.15% <ø> (ø)
src/awkward/operations/ak_argcartesian.py	78.94% <ø> (ø)
src/awkward/operations/ak_count.py	96.00% <ø> (ø)
src/awkward/operations/ak_count_nonzero.py	96.15% <ø> (ø)
src/awkward/operations/ak_from_parquet.py	89.39% <ø> (ø)
src/awkward/operations/ak_nan_to_none.py	23.52% <0.00%> (ø)
src/awkward/operations/ak_prod.py	87.09% <ø> (ø)
src/awkward/operations/ak_sum.py	90.32% <ø> (ø)
src/awkward/operations/ak_transform.py	91.30% <ø> (ø)
... and 61 more

[agoose77]

I added a helper function to identify non-str iterables, and the rest is all you!

[jpivarski]

That helper function can be used in quite a few other places. The ak.Array constructor effectively makes the same test by first making one choice based on whether the given data is a string and then later handling the iterable case.