feat: add string formatter to ak.Array.show

[agoose77]

This PR closes #1281 by adding support for a subset of NumPy's printoptions simple string formatting configuration. These options are compatible with NumPy's formatting options, apart from strings (only str_kind is compatible with both libraries):

• NumPy's "numpystr" is ignored
• Awkward's "str" and "bytes" are used for str/bytes

N.B. we use the g conversion type, which is different to NumPy's default mode.

Precision:

>>> ak.Array([1.0, 2.02313123123123123123123123]).show(precision=4)
[1,
 2.023]

Formatter:

>>> ak.Array(["foo", "bar"]).show(formatter={'str': "<STRING {!r}>".format})
[<STRING 'foo'>,
 <STRING 'bar'>]

I don't think we need to fully replicate NumPy's features here, or support their options context. This PR should add enough control for some additional use cases.

[codecov]

Codecov Report

Merging #2803 (3c72134) into main (015a362) will increase coverage by 0.12%.
The diff coverage is 93.33%.

Additional details and impacted files

Files	Coverage Δ
src/awkward/highlevel.py	77.40% <66.66%> (+0.71%)	⬆️
src/awkward/_prettyprint.py	85.57% <95.49%> (+12.39%)	⬆️

[jpivarski]

This is great! Also, I'm glad this is opt-in, so the default precision is still 3 digits. But if someone needs to see more, we can point them to this.

It's also nice that this is following existing conventions, so the documentation only needs to reference https://numpy.org/doc/stable/reference/generated/numpy.set_printoptions.html.

[agoose77]

I'm glad this is opt-in, so the default precision is still 3 digits

@jpivarski note that the default precision for complex numbers will increase after this PR: https://github.com/scikit-hep/awkward/pull/2803/files#diff-9d47b8746eed8b0f77589c076ef5be2891fec7d0acd9d41f04dac9cc9bbb1076L227

Are you OK with that change? I'm thinking it's fine; few people are likely using complex numbers, and fewer still should be relying on the string representation. Ideally we'd gracefully handle this but I don't think it's worth the added complexity.

[jpivarski]

I had checked out the code and had tested it with a floating point value, so I missed the fact that the complex precision used to be 2 digits

>>> ak.Array([np.pi + np.pi*1j]).show()
[3.1+3.1j]

but will now be 3 digits

>>> ak.Array([np.pi + np.pi*1j]).show()
[3.14+3.14j]

The rationale for shorter complex numbers must have been because they use up so much space anyway, with two values, a + and a j. But I don't think this is worse. (Also, no, nobody should be relying on the text representation of numbers. We should be allowed to change that.)

The limit_cols argument gets more important, once one starts expanding the numeric representations.

This PR can be merged.