fix: restrict named_axis inferring to ak.Arrays/ak.Records/ak.HighLevelContexts by default

[pfackeldey]

This PR is a follow-up to PR #3299. The named_axis mapping is now only inferred from awkward-constructs (ak.Array, ak.Record, and HighLevelContext) by default. This avoids likely unwanted clashes with objects that implements the named_axis mapping interface (for whatever reason) but are not meant to be used this way. I expect this to happen in very rare corner-cases. This PR covers them now. An example is given below:

Old behavior:

from awkward._namedaxis import _get_named_axis, NAMED_AXIS_KEY


class some:
  @property
  def attrs(self):
    return {NAMED_AXIS_KEY: {"x": 0}}
    
_get_named_axis(some())
>> {"x": 0}

New behavior:

from awkward._namedaxis import _get_named_axis, NAMED_AXIS_KEY


class some:
  @property
  def attrs(self):
    return {NAMED_AXIS_KEY: {"x": 0}}
    
_get_named_axis(some())
>> {}
 
# old behavior can be enforced by:
_get_named_axis(some(), allow_any=True)
>> {"x": 0} 

If we want to infer named_axis from any types again somewhere in the future, the allow_any argument will allow us to do so.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.49%. Comparing base (b749e49) to head (0626e58).
Report is 199 commits behind head on main.

❗ There is a different number of reports uploaded between BASE (b749e49) and HEAD (0626e58). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (b749e49)	HEAD (0626e58)
	2	1

Additional details and impacted files

Files with missing lines	Coverage Δ
src/awkward/_broadcasting.py	92.41% <ø> (-2.94%)	⬇️
src/awkward/_namedaxis.py	91.19% <100.00%> (ø)
src/awkward/operations/ak_mean.py	88.46% <ø> (+1.22%)	⬆️
src/awkward/operations/ak_moment.py	92.85% <ø> (+0.85%)	⬆️
src/awkward/operations/ak_ptp.py	97.43% <ø> (+0.37%)	⬆️
src/awkward/operations/ak_std.py	87.50% <ø> (+1.45%)	⬆️
src/awkward/operations/ak_var.py	84.21% <ø> (+1.51%)	⬆️

... and 177 files with indirect coverage changes

[jpivarski]

Great! (We talked about this elsewhere, maybe Slack.) Was there an issue opened about this by @veprbl? Does this PR close that issue?

[pfackeldey]

No, there's no open issue. Restricting this behavior came up in a discussion between us regarding the vector issue scikit-hep/vector#524, but it is not directly related to it. This issue has been closed by #3299.

[jpivarski]

Oh, I see. Well, you can merge this PR when you're ready (probably now).